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