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.
On 9/19/12, Per Bothner <per@xxxxxxxxxxx> 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