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