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
xxxxxx@bothner.com   http://per.bothner.com/