Hmm, a new fly in the ointment for \-as-symbol. I've found that using symbol \ as SPLIT/GROUP symbol has an implementation complication for anyone who also wants to support slashification inside (...). And I expect some reader implementations *will* want to slashification, at least inside (...).
I think that is a negative against using \ as GROUP=SPLIT; let me explain. First: I've merged in a 2-line patch so that the SPLIT symbol is only considered as such if it BEGINS with the first split character. This means that, if SPLIT is \, you can escape it using (. \). This is great, we can escape the SPLIT symbol easily, instead of the old GROUP GROUP approach. EXAMPLES: \ . a b => ((a b)) (. \) . a b => (\ (a b)) HOWEVER, this presumes that NO implementation will EVER want slashification. It would make sense to implement arbitrary slashification inside (...), since SPLIT cannot ever have that meaning inside (...), but that turns out to be more complicated to implement. The problem is that when the modern-expression reader is invoked, indentation processing may be on - or it may be off. So when the modern-reader sees \ space as the first two characters, it doesn't know what to do. Common Lisp requires slashification, and the Scheme spec specifically notes slashification as a possibility, and I'm pretty sure that several Scheme implementations support it (I'm not sure how many, I suppose we could check). So while not everyone needs to support slashification, making it unusually *hard* to do seems like something to avoid. We could create two entry points for the modern-expression reader, or an extra parameter, so it'd know if indentation processing is active (and thus if initial slashification is okay). But that's annoying to use, and is otherwise unnecessary. Also, this extra parameter would spread through any modern-expression reader implementation. This implementation problem does NOT happen with other symbols. Changing to another symbol, like ! or ~, makes it go away completely. BTW: I don't think we even have to have a single-character symbol for SPLIT, our current implementation handles that easily. I *do* think that the SRFI-49's use of the symbol "group" was a mistake - it's very confusing to have *alphabetic* symbols have a special meaning (especially one with potentially other uses). Now granted, we might have other escaping mechanisms for the SPLIT (GROUP?) symbol, but it's important that we have one, and (. EXPR) is a pretty good one (it doesn't interfere with existing code). --- 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
