Re: [Scheme-reports] Formal Comment: Change syntax of symbols from |<symbolelement>*| to #"<string element>*"

[Cory Burgett <cmburget@x>]

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@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports