Regarding square brackets....

John Cowan:
> R6RS imposes this requirement, but R7RS does not.

True, but since treating [] as a synonym for () *IS* in R6RS, a large number of Scheme implementations (20!!) implement [] as synonyms for ().  And since R6RS imposes it, I believe there's a fair amount of code that uses it.  I think that many implementations will continue to support [] as a synonym for (), in part because of the amount of code that uses it.

> You can't just say "Brackets mean what
> they mean in Scheme", because there is and will be no unified meaning.

By intent, the current draft SRFI-105 spec simply doesn't define unprefixed brackets at all. Different Scheme implementations do different things, as you've already noted.  Other Lisps do other things too, for example, Arc has a completely different meaning for [...].  So I believe the spec should *not* impose any particular meaning on unprefixed [...]; there are too many cases where established code requires a particular (but varying) meaning.

If someone wants that to have a specific meaning for unprefixed [], I think that should be part of a different spec.  I don't think we need to require any particular definition of [...] to meet our goals.  Even more importantly, I think trying to force one meaning would greatly *decrease* adoption.

> 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 demo implementation implements [] as a synonym for (); see the code for underlying-read.  I think this is far more widely used meaning, and it makes sense as a demo.  But it's not a requirement of the spec; it's just a fact about the demo.  (The demo implements basically an R5RS reader plus a few R6RS extras and other extensions, in an effort to make it "useful enough" as a demo.)

The intent is that people would modify their readers to implement SRFI-105, at which point, [...] will do whatever their reader already does.

--- David A. Wheeler