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

[Peter Bex <Peter.Bex@x>]

On Sun, Apr 08, 2012 at 06:32:21PM -0500, Alan Watson wrote:
> 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.

Very well-worded.

> 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.

+1.  Please implement it exactly like that in the spec.

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"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
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports