Minor last-minute issues
John Cowan
(18 Sep 2012 17:45 UTC)
|
Re: Minor last-minute issues
Per Bothner
(18 Sep 2012 18:40 UTC)
|
Re: Minor last-minute issues
John Cowan
(18 Sep 2012 18:59 UTC)
|
Re: Minor last-minute issues
David A. Wheeler
(18 Sep 2012 21:32 UTC)
|
Re: Minor last-minute issues
Per Bothner
(18 Sep 2012 21:54 UTC)
|
Re: Minor last-minute issues
David A. Wheeler
(19 Sep 2012 00:03 UTC)
|
Re: Minor last-minute issues
Per Bothner
(19 Sep 2012 00:46 UTC)
|
Re: Minor last-minute issues
Alan Manuel Gloria
(19 Sep 2012 01:16 UTC)
|
Re: Minor last-minute issues
John Cowan
(19 Sep 2012 02:22 UTC)
|
Re: Minor last-minute issues Alan Manuel Gloria (19 Sep 2012 12:27 UTC)
|
Re: Minor last-minute issues
David A. Wheeler
(19 Sep 2012 13:44 UTC)
|
On Wed, Sep 19, 2012 at 10:22 AM, John Cowan <xxxxxx@mercury.ccil.org> wrote: >> For Scheme as of R6RS, [x ...] means (x ...), so that's what SRFI-105 >> (which is specific to Scheme) says. > > R6RS imposes this requirement, but R7RS does not. See > http://trac.sacrideo.us/wg/wiki/BracketsBraces for details of which > Schemes do what with brackets. You can't just say "Brackets mean what > they mean in Scheme", because there is and will be no unified meaning. > > Since you're providing a full implementation modulo the change to > the readtable, you need to make some decision for the purposes of that > implementation, and it's not clear to me what it should be. The advantage > of Kawa's $bracket-list$ convention is that it can be mapped to treating > [] like (), but it can be mapped to something else too, at the will of > the user. > Hmm, how about "unprefixed square brackets mean whatever they mean normally in the Scheme implementation; if the Scheme implementation does not have any particular intended meaning, it should use the R6RS meaning."? I don't really see "we need a unified meaning for unprefixed [ ]" to be an important requirement; basically, the intent is that unprefixed [ ] means the same as [ ] outside of n-expr syntax. After all, it seems that currently portable Scheme code can't depend on any particular interpretation for [ ] anyway, so it's not really being worse off - and I dunno, maybe it'll help adoption a bit? I'll let David consider this first, in any case the above is what is intended for unprefixed [ ] in the general syntax of n-expressions. Sincerely, AmkG