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.
Per Bothner scripsit:
> First, a question: Do you have any objection to plain & for SRFI-109
> strings:
> &{text}
No, that's fine.
> 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.
I can live with that. I have yet to be convinced once and for all that
initial-expressions are actually as useful as all that. I'd rather
leave them as an optional extension.
> But in this case I lean towards preferring the nicer syntax,
> given that it may be hard to find actual programs that would break.
Probably, but the difference is one of whitespace only, and it makes
(foo &condition [bar 1 2])
and
(foo &condition[bar 1 2])
differ very radically. If initial & was rare, I'd probably feel better
about this, but it's common in SRFI 35 or R6RS code that deals with
conditions.
> 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.
I agree.
--
While staying with the Asonu, I met a man from John Cowan
the Candensian plane, which is very much like cowan@xxxxxxxx
ours, only more of it consists of Toronto. http://www.ccil.org/~cowan
--Ursula K. Le Guin, Changing Planes