[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: updated SRFI-108

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/