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.

.  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 
Readable-discuss mailing list

Reply via email to