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