bear wrote:
>> At this point I have only one question:  For a rank-5
>> array, why #5A(...) instead of #A5(...)?

Per Bothner wrote:
> Maybe #A5 is marginally better, but I think compatibility with the
> prior art of Common Lisp argues for #5A.  That's not an overwheming
> argument, but (I think) tips the scales in favor of #5A.

Putting the rank first is likely to cause confusion for PLT users. PLT
Scheme has a shorthand notation for vectors with repeated elements:
#N(<E0>...<Ei>) is shorthand for a vector N elements long, with <Ei>
repeated as many times as necessary to produce N total elements. For
example, #5(0 1) is shorthand for #(0 1 1 1 1). Likewise, #N() is
shorthand for a vector of N zeroes; #5() is shorthand for #(0 0 0 0 0).

It'd be confusing to mix #5(...) and #5A(...) syntax: Only a single
character distinguishes between "a vector of five /elements/" and "an
array of five /ranks/." I'd expect users to occasionally mistype and
misread the dimensions.

Furthermore, I think it's a mistake to give the number of ranks instead
of the dimension bounds. As I explained in a reply to Bear, you can't
infer array shape from a list decomposition if the array has any
0-bounded dimensions.

Instead, the external representation for arrays should list the
dimensions (e.g., #A2x3(...) or #A:2:3(...)). This permits unambiguous
reading and writing of "empty" multi-dimension arrays, it permits the
PLT shorthand notation for large, repetitive arrays, and it avoids
confusion with the #n(...) syntax for vectors.

> More technical argument: What happens with a rank-0 array? In APL this
> is equivalent to a scalar, and in any case a rank-0 array has a single
> element.  Given the choice between #A0XXX and #0AXXX, the latter is
> better since the former leads to ambiguities.

I don't think the Scheme reader should support this "array notation" for
scalars. The Scheme writer should never produce it, and I suspect that
very few human writers would ever use it. Even if you did want to
support it, I think it'd be reasonable to require a separator (space)
between the #A... token and the scalar.

>> I'm thinking about parsers here, where it's easier on everybody if
>> tokens differ as soon as possible.

> A (non-human) parser handles either just fine - except
> for the degenerate rank-0 case.

I don't think that's true for dialects (like PLT Scheme) that already
use #N... syntax for something else.
--
Bradd W. Szonye
http://www.szonye.com/bradd