>From: "David A. Wheeler" <xxxxxx@dwheeler.com>
Subject: Re: SRFI 105: Curly-infix-expressions
Date: Mon, 27 Aug 2012 23:15:01 -0400 (EDT)

> Shiro Kawai:
>> R6RS #!-switch is the closest I can think of that can make a
>> source file self-descriptive about the lexical syntax it uses.
>> Did you think about using something like #!c-expr ?
>
> To answer your question, I did think about creating some marker, but I didn't want to clutter the language with a special marker like that.  Earlier versions mandated "(enable-curly-infix)" with the same idea; the advantage of that approach is that it doesn't have to even have cooperation by the reader (as long as there's some way, in that implementation, to override the reader).  It's still there, but merely as a "may".

We already have #!r6rs, #!fold-case and #!no-fold-case.  I can
see #!-markers can be easily abused, but C-expr is a disruptive
lexical syntax change big enough to justify using it, IMHO.
And with #! marker it is clear that when the reader sees it.
With a procedure or a macro, it's not clear when it takes effect.

BTW, I think you can drop "(enable-curly-infix)" completely.
Other than using it in a single-threaded simple REPL interaction,
a user can't assume much how it works unless it consults
each implementation's documentation (e.g. what if concurrent REPL
is running?  what if he loads a file that contains both
(enable-curly-infix) and C-exprs? etc.)   Then he could just
use implementation-specific way to enable C-exprs as well.
It can't use as a part of portable code, either.
Merely having a common name doesn't seem to offer much.

> Instead of cluttering every source file, the draft instead opts to make it an implementation invocation, e.g,. "curly-guile" or whatever.  Then, if you have source code that may use it, you can invoke it to start with.

I certainly see the point of making C-expr default.  It may depend
on how many implementations have (ab)used '{}' for other purposes.
I'm ok to put it up to the community's vote.

--shiro