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 11/24/2012 07:39 PM, John Cowan wrote:
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 }}}};
We certainly can; I'm not yet sure that would be my preference. Especially since if we keep "initial expressions" (which I think is best) - in thar case we need to use brackets as well.
actually, I find those more readable than )])] or }]}].
That I can sympathise with ...
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?
With initial expressions, it corresponds to #&foo{bar baz}
It can't be #&foo[&{bar baz}], because the grammar does not allow that.
Actually, the grammar does. However the translation (in SRFI-107) is wrong.
It should be:
TrContent[&{expression...}]
==> expression ...
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.
Right - but such concatenation is likely to be common. Many simple constructors will just concatenate the strings and then parse the resulting string in some matter.
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.
Not really. If you have to handle multiple non-empty strings, then handling empty strings isn't a problem. -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/