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

Re: Minor last-minute issues

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



John Cowan:
> Ticket #486 to make braces delimiters in R7RS failed for lack of a second

Anything we can do?

> so SRFI-105 needs to say explicitly that they are delimiters.

It's already there:
"A curly-infix reader must include the braces “{” and “}” as delimiters."

> I mentioned this before but it seems to have gotten lost: I recommend
> that [foo bar] in c-expressions be treated as ($bracket-list$ foo bar)
> rather than (bracketaccess foo bar).  This is compatible with Kawa,
> which is the only Scheme in my test suite to treat square brackets in
> this way.  In FemtoLisp and Rep, they are used for vector datums; in
> all other Schemes, they are synonyms for parentheses per R6RS, regular
> identifier characters, or lexical syntax errors.

I'm not sure I understand.  I intentionally didn't discuss unprefixed [...], so that people can do what they want; curly-infix doesn't define anything for the unprefixed case.  Does Kawa actually map x[foo bar] to ($bracket-list$ x foo bar)?

> In any case, $bracket-list$ or bracketaccess should be specified as
> being like nfx: no definition by default.

Good point.

--- David A. Wheeler