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
xxxxxx@bothner.com   http://per.bothner.com/