[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SRFI-10 syntax vs. #nA syntax
>> 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
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