I think it's important to release an updated spec soon with the new {}, {e},
{e1 e2}, and f{} semantics. In particular, I'd like to be consistent with the
SRFI curly-infix submission. By "soon" I mean 0-2 days.
There are obviously questions about dropping (. e) mapping to e, so I think we
should just keep it. We can drop it later if we need to.
I agree that it's important to define #whitespace in sweet-expressions, but I'm
not sure we've done it properly. I think we need more time to work out (and be
CONFIDENT) in the specification for that; I'd rather say nothing about it than
say the wrong thing. I think most users won't even notice the omission :-).
So I'd like to release a 0.5 version, without a careful #comment definition.
After all, we've already done it several times :-).
--- David A. Wheeler
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
