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

Re: Lexical syntax for boxes

This page is part of the web mail archives of SRFI 111 from before July 7th, 2015. The new archives for SRFI 111 contain all messages, not just those from before July 7th, 2015.

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:


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.

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