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

Re: SRFI-108/SRFI-109 special characters



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