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

Re: SRFI-108/SRFI-109 special characters

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:
     ==> 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:
     ==> ($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/