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

Re: SRFI-108/SRFI-109 special characters



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".
The "xml-style" (red) in the proposal is the latter.
If we go with xml-style I would prefer that as it is what
the Kawa implementation currently does for XML literals.
(In a pinch I could support both [] and {} to enclose
expression in Kawa, deprecating the {} syntax.  I don't know
how many people actually use Kawa XML-literals.)

This use of braces will not
conflict with SRFI-105, nor will it conflict with the existing uses of
brackets as alternative parens.  (In Chicken, braces are also alternative
parens, unfortunately, but that can be changed.)

I don't believe either "xml-style" or "scribble-style" (or certain other
possible variations) directly conflict with SRFI-105 or brackets as
alternative parens.

In Scribble-style braces are used for (quasi-)literal text immediately
following a '@' (SRFI-109) or '@NAME' (SRFI-108).  The former doesn't
conflict with SRFI-105 at all.  The latter only conflicts if '@NAME'
is a valid standalone token followed by an SRFI-105 curly-form.
Scriblle-style SRFI-108 does not propose that standalone @NAME be valid -
it has to be immediately followed by either (EXPR...) or [EXPR...] or
{TEXT}.  Likewise, square brackets are only special following '@' (and
optionally a format-specifier).

Likewise, in XML-style {} or [] are only significant following '&',
so other uses shouldn't be a conflict.

Of course one could argue about readability or error-proneness -
some variations may be better than others.
--
	--Per Bothner
per@xxxxxxxxxxx   http://per.bothner.com/