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