After fiddling, I'm thinking we should handle length 0 curly-infix expressions
specially, CHANGING the semantics of {} and f{} specifically. This isn't a big
change, it's an edge case, but I'd like to get it right. Let's talk!
Currently, the empty curly-infix-expression {} means (nfx). That's defensible,
but it is weird, and it's subtly inconsistent with the idea that {} is
basically a slightly different list notation. After all, () IS an empty list.
But more importantly, this means that the neoteric-expression f{} maps to (f
(nfx)), not to (f).
That interpretation of f{} is unlikely to be what the user intended. I think
it's quite likely that since people will use f{...} for an infix list, they
will occasionally write f{} expecting it to map to (f). While we can't prevent
all mistakes (!), if we can define the semantics constructs have their
"expected" meaning that'd be a good thing. These meanings of {} and f{} are
very unlikely to be the user's intent. And if the user really means that,
there are already clearer ways to write that: (nfx) or nfx() for the first
case, and (f (nfx)) or f(nfx()) for the second case.
So I propose the following semantic changes:
* Curly-infix: If the length is 0, return () not (nfx).
* Neoteric-expressions: Given e{...}, if the curly expression {} returns (),
map it to (e).
--- 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
