On 9/19/12, Per Bothner <xxxxxx@bothner.com> wrote:
> On 09/18/2012 05:03 PM, David A. Wheeler wrote:
>> Per Bothner:
>>> No. Kawa maps:
>>> [foo bar] to ($bracket-list$ foo bar)
>>
>> I think we should *not* require a particular definition for unprefixed
>> [...].
>
> It's a bit weird to have a (reader) definition for F0[F1 F2] but not [F1
> F2].
>
>>  Many Schemes use that as a synonym for (...), and I want to minimize
>> syntactic changes
>
> The convention seems to be to use [...] for a "clause" - i.e.
> where [...] is used definitions and other forms for grouping of
> things that aren't expressions.  One could implement these forms so
> they recognized ($bracket-list ...) - though I'm not sure that
> is worth the effort.  (I tried to do so, but gave up without
> getting very far.)

The intent is that curly-infix will be used not only in Scheme, but also in
other Lisplikes: CL, Arc, Clojure, ELisp, etc.  We only started in Scheme
because it seemed to be the only one with any kind of public
peer-review process for extending the language (namely, the SRFI
process).  We'll get to the others once we locate some kind of public
process for extending those languages.

Now, in some languages (Arc,Clojure) a non-prefixed [x ...] has
some special meaning: in Arc that's (fn (_) (x ...)), in Clojure that's
a readersyntax for vectors.

Since we want to make these syntaxes compatible with as many
other Lisplikes as we can get, David decided that non-prefixed
[x ...] means "whatever the underlying Lisplike says it means", and I
(Alan) mostly concurred.  The only modification is that a prefixed
foo[x ...] means (bracketaccess foo x ...).

For Scheme as of R6RS, [x ...] means (x ...), so that's what SRFI-105
(which is specific to Scheme) says.

>
>> (such differences would be a source of bugs).
>
> If we're talking about forms purely within curly-braces, or
> in a library that is marked with #!curly-index, then I'm not
> sure there needs to be a conflict.

Curly-infix is a subset of the entire readable-lisp stack, and
so we (at least David and I, or at the bare minimum David,
since I'm quite fine with Scheme anyway ^^) need to worry
about conflict when an entire library *for a specific language*
needs to access the language-specific [x ...] construction while
using the higher-level t-expr (sweet-expressions) syntax.

Sincerely,
AmkG