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
> 0-bounded dimensions.

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
mzscheme: #2x3(...)

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
> scalars.

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
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/