[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Symbol escapes - clarification
On Mon, Jan 09, 2012 at 11:12:07AM -0500, John Cowan wrote:
> I am not sure I understand this. \-escaping *is* allowed within
> |-escaping, so |(\x3BB;)| is the identifier "parenthesized lambda".
> Indeed, there is a ticket pending to disallow \-escaping by itself and
> allow it only within |-escaping. That would allow \ to be an ordinary
> identifier character.
In "bare" symbols I'd expect anything but s-expression delimiters
(spaces, parens, semicolons and possibly single quotes, commas and
backticks) to be allowed but no "special interpretation" of composite
characters. This keeps the reader simple; just consume characters
until you find an s-expression metacharacter.
> > - CL also has '|'-escapes but they don't delimit symbols, so
> > |abc|def|ghi| is read as a single symbol abcDEFghi. R7RS doesn't
> > explicitly say '|' delimits the symbol, but also doesn't seem to
> > allow |abc|def syntax according to 7.1.1. I'm fine with either way,
> > but was it a conscious decision?
> It was a conscious decision to make vertical bars delimit the symbol, in
> the same way that quotes delimit a string. The wording of 2.1 is meant
> to imply this: a symbol can begin with |, contain arbitrary characters
> or inline hex escapes, and end with |.
I think I've argued this point before, but it would be more consistent
to allow \ to escape the | so that || acts exactly analogously to ""
in strings, where backslashes escape the delimiter.
This is simpler, more regular and allows implementation to use the same
routine for reading strings and symbols (with the delimiter as parameter).
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth
Scheme-reports mailing list