Email list hosting service & mailing list manager


Re: SRFI-108/SRFI-109 special characters Per Bothner 24 Nov 2012 09:21 UTC

On 11/23/2012 10:55 PM, John Cowan wrote:
> Per Bothner scripsit:
>
>> On 11/18/2012 01:22 PM, John Cowan wrote:
>>
>>> I strongly prefer XML-style with braces.
>>
>> Both forms use both braces and brackets, so I'm unclear
>> whether you mean "XML-style with braces for literal text"
>> or "XML-style with braces for escaped expressions".
>
> I meant the former, eliminating the whole idea of initial expressions.
> They seem to be insufficiently justified in this draft (to be sure, it
> says "examples needed", which I can only agree with).  If there are no
> initial expressions, then square brackets need not be used, and braces
> suffice for both quasi-expressions and unquoted expressions.  Given that
> there is substantial disagreement in the Scheme world about what, if
> anything, square brackets should be for, I consider it wise to avoid them.

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.

You could probably do that, but I think it slightly hurts readability
for a pretty limited gain.

> 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.

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.

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.  It seems more consistent
to leave them in. Consider the progression:
#&cname[klm&{exp1}abc&{exp2}xyz]
     ==> ($quasi-value$ cname "klm" exp1 "abc" exp2 "xyz")
#&cname[kl&{exp1}ab&{exp2}xy]
     ==> ($quasi-value$ cname "kl" exp1 "ab" exp2 "xy")
#&cname[k&{exp1}a&{exp2}x]
     ==> ($quasi-value$ cname "k" exp1 "a" exp2 "x")
and in the limit:
#&cname[&{exp1}&{exp2}]
     ==> ($quasi-value$ cname "" exp1 "" exp2 "")

> I think your remark that Scribble-style is not really compatible with
> Scribble is enough to sink the idea.  It's hard to maintain two subtly
> different lexical syntaxes in one's head.  The XML-style is really not
> much like XML, and creates no mental conflicts.

I'd be curious to hear from people with Scribble experience.  Would you
rather have something that is similar to Scribble, but not 100% the same
syntax, or something totally different?
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/