Email list hosting service & mailing list manager


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)