This page is part of the web mail archives of SRFI 108 from before July 7th, 2015. The new archives for SRFI 108 contain all messages, not just those from before July 7th, 2015.
On 02/04/2013 12:16 AM, John Cowan wrote:
Per Bothner scripsit:I've settled on the &name[initial-exp]{text} syntax, which is a hybrid of the XML syntax (in using & rather than @) and the Scribble syntax (in using a single prefix character rather than #&, and in the use of brackets/braces).It continues to disturb me that "&name[initial-exp]" already has a meaning in R6RS, such that this is not an upward compatible extension. I still strongly prefer #& to plain &, especially as identifiers beginning with & are actually in use in R6RS.
First, a question: Do you have any objection to plain & for SRFI-109 strings: &{text} That does not conflict with R6RS, nor (as far as I know) with any common extension. I think the argument for plain & is strong for strings, since the following is rather ugly and easy to mistype: #&{text} A possible solution/compromise is to *require* that "&name[initial-exp]" be followed by a braced-delimited literal part, if necessary empty: &name[initial-exp]{} This avoids the incompatibility. It makes parsing slightly more complex, but the extra code and state needed is small. This only one character longer than: #&name[initial-exp] plus of course being shorter in the case of a non-empty named-literal-part. One can still make the braces optional inside for an enclosed extended-datum-body inside a named-literal-part, since there is no conflict in that case. Some implementations (e.g. Kawa, most likely) may make the empty braces optional when named-literal-part is empty. Given a trade-off between 100% backwards compatibility vs a more elegant forwards-looking syntax there is no general right answer. But in this case I lean towards preferring the nicer syntax, given that it may be hard to find actual programs that would break. Beyond preferring a shorter and less "line-noise-like" syntax, a major reason for not requiring the initial "&" is have the same syntax for top-level extended-datum-literal as for nested extended-datum-body. And for the latter we can't use "#&" without making "#" special in a literal-part. (Well, we could make "#"-only-if-followed-"&" special, but that seems silly.) It is also good to avoid the issue of "#&" vs "&#" (character reference), which is another reason I want to avoid "#&". For XML literals I think we're stuck with "#<TAG..." rather than "<TAG..." since the latter conflict with existing code an standards is much more difficult. For example some Schemes have "<type-name>" which is obviously a pretty nasty conflict. -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/