[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SRFI-10 syntax vs. #nA syntax
Bradd W. Szonye wrote:
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
Wild idea (where 'type' is optional):
#[bound ...]type(elements ...)
This would be the API "rho" operation, if I remember correctly.
Elements would be the "unravelled" values in row-major-order.
E.g. #[2 3]int32(11 12 13 21 22 23)
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.
My main objection is that it looks too close to the Common Lisp syntax.
E.g. #A2((1 2) (3 4)) could easily be a typo for #2A((1 2) (3 4))
which means something very different.
Hence, I'd leave out the A, and make the syntax compatible with
There is a question of whether the elements should be shown flattened
or nested: #2x3(11 12 13 21 22 23) or #2x3((11 12 13) (21 22 23))
There is also a problem in that the syntax fails in the case of rank-0
arrays. That is an argument for leaving in the 'A'.
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
I didn't mean to suggest that. I just mentioned it as a "by the way".
However, a Scheme that support general arrays should still support
0-rank arrays, and so we need to consider the degenerate case.
With my suggested syntax, it would be: #234