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

Re: SRFI-108/SRFI-109 special characters

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.



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,                                    cowan@xxxxxxxx
Issue lots of Drafts.                           http://www.ccil.org/~cowan
So much more to understand!
Might simplicity return?                        (A "tanka", or extended haiku)