Re: SRFI-108/SRFI-109 special characters John Cowan 25 Nov 2012 03:39 UTC
Per Bothner scripsit: > You mean: > #&{Total &{sum}.} ;; String > #&URI{http://&{example-host}/} > > I.e. #&{ or #&NAME{ In Scheme mode start literal text, while &{ in > literal mode starts an enclosed Scheme expression. The first format I'll address on the SRFI-109 list, but the second format, yes. In full: #&name{...} is a quasi-literal in Scheme-mode. Within a quasi-literal, &{...} is an enclosed expression, &name{...} is an embedded quasi-literal. > You could probably do that, but I think it slightly hurts readability > for a pretty limited gain. Eh, if we can live with )))), we can live with }}}}; actually, I find those more readable than )])] or }]}]. > >But if initial expressions are to be kept, I don't see why the example > >#&cname[&{exp1 exp2}text} should be expanded into something involving > >an empty string. Does #&cname[&{exp1}&{exp2}] expand to ($quasi-value$ > >cname "" exp1 "" exp2 "")? Surely not. > > Surely they do - or at least that's what I'm proposing. It seems excessive, > but it allows cname's macro-transformer to determine the structure of the > quasi-literal - if it wants to. Consider the reverse direction. If (foo "" bar "" baz "") corresponds to #&foo[&{bar}&{baz}], then what in the absence of initial expressions does (foo bar baz) correspond to? It can't be #&foo[&{bar baz}], because the grammar does not allow that. > An example where this matters is in the XQuery language, where you have: > <b>{1}{2}</b> ==> <b>12</b> > <b>{(1,2)}</b ==> <b>1 2</b> > I.e. it may be important to tell the boundaries of enclosed expressions. In S-expressions, though, the former case doesn't arise, because #&b[&{1}&{2}] ==> (b 1 2) on my assumption or (b " " 1 "" 2 "") on yours; if you want (b 12) you have to do something at runtime to concatenate these expressions. > I don't think this ability is a must-have, and it may be reasonable to > leave out the empty strings is that simplifies writing expanders, but > for now I think it is better to have them. I can't see any context in which it buys you anything, considering that each enclosed expression and (maximal) string of text corresponds to a single subform in the S-expression representation. > and in the limit: > #&cname[&{exp1}&{exp2}] > ==> ($quasi-value$ cname "" exp1 "" exp2 "") Yes, I see that, but it seems like overkill still. And it does complicate writing a syntax-rules macro with ... elimination, where the ... has to iterate over the unwanted empty strings as well. -- Winter: MIT, John Cowan Keio, INRIA, xxxxxx@ccil.org Issue lots of Drafts. http://www.ccil.org/~cowan So much more to understand! Might simplicity return? (A "tanka", or extended haiku)