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

Re: Lexical syntax for boxes



On 05/22/2013 08:12 AM, John Cowan wrote:
Alex Shinn scripsit:
SRFI-108 is pretty huge and scares me somewhat.

It's basically Scribble with a slightly different syntax, meant to
share syntax with SRFI-109 quasi-strings.  The major non-syntax
issue is that a tag &foo maps to $construct$:foo rather than plain foo,
to allow different bindings for &foo and foo.

I think the core is pretty simple.  For objects you want to initialize
from a literal string, you write:

     &name{string}

which is lexed as

     ($construct$:name "string")

If you want expressions instead, you write:

     &name[expr expr expr]

Actually, at your request, the specification
requires a following {}.  I.e.

     &name[expr expr expr]{}

This is because of concerns about ambiguity with &foo
as a name, for example for an exception-type.

Kawa does not require the '{}'.  Personally, I don't
think the ambiguity is a real problem: &foo immediately
followed by '[' with no intervening spaces can be read
pretty unambiguously a SRFI-108 form.


which is lexed as

     ($construct$:name $<< expr expr expr $>>$)

where $<<$ and $>>$ are variables defined by the implementation as
distinct objects, typically empty strings.

Actually,
     &name[expr expr expr]{}
is lexed as:
     ($construct$:name expr expr expr $>>$)
i.e. without the initial $<<$.  This is to allow disambiguating
     &name{&[expr expr expr]}
which is lexed as:
     ($construct$:name $<<$ expr expr expr $>>$)
--
	--Per Bothner
per@xxxxxxxxxxx   http://per.bothner.com/