Alan Watson <alan@...> writes:

>
> I'd urge WG1 to reconsider their current approach to "difficult" symbols. At
the moment, there are a number
> of things that give strong hints of an unfinished design:
>
> * There are two mechanisms to write difficult symbols. Now, that's not
necessarily a bad thing, but such
> duplication needs to be justified. For example, one can justify the three ways
to write the space
> character, #\ , the variants on #\x20, and #\space because the first two,
while specific applications of
> general rules, are not sufficiently transparent and therefore the third is
useful. I'm not sure I see the
> need for two different mechanisms to write difficult symbols.
>
> * The vertical-bar syntax has arbitrary restrictions; I cannot use it to write
a symbol containing a
> vertical bar or a backslash other than by using hex escapes.
>
> * There are strong parallels between strings and symbols, yet the mechanisms
used to write them do not
> exploit there parallels.
>
> I would suggest:
>
> * Dropping hex escapes in symbols outside of the vertical-bar syntax.
(Specifically, eliminate <inline
> hex escape> from the <initial> rule.)
>
> * Extending the vertical bar syntax so that it is identical to the string
syntax, except that the delimiter
> is the vertical bar rather than double quotation and the \| escape replaces
the \" escape. (Specifically,
> the syntax for <symbol element> should look like the syntax for <string
element> with the two occurrences
> of double quotation replaced by vertical bar.)
>
> This gives one mechanism for writing difficult symbols, and furthermore one
without arbitrary
> restrictions and with strong parallels to strings. This is backwards
compatible with implementations
> that follow the current grammar for vertical-bar symbols, since the current
grammar forbids escapes and
> this mechanism essentially extends the current syntax with a full range of
escapes. Furthermore, it will
> be relatively simple to implement, since one simply has to adapt the code for
reading strings to a new
> delimiter and escaped delimiter.
>
> Regards,
>
> Alan
>

I would also like to second this.  My toy implementation does this, and it's
indeed trivial to extend the string reader to delimited symbols.  I've found
that symbols as described by Alan are very intuitive to use, given that the
rules are the same as strings (and what are symbols anyway if not interned
strings?)

-Cory

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports