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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
