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.

Per Bothner wrote:
> 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)

Not bad, but I like your later suggestion for #MxN(...) even better:

>> 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 [to #A2x3(...)] 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.

Good point!

> Hence, I'd leave out the A, and make the syntax compatible with
> mzscheme: #2x3(...)

I thought of that too (after I'd already sent my comment above). I like
the idea even better now that I've seen it in type. I especially like
how a one-dimensional array in this syntax looks exactly like the PLT
vector shorthand (e.g., #5(1 2 3 4 5)). It should be a painless upgrade
for MzScheme users.

> 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))

I prefer the nested syntax; it seems like it would support the
repeat-last-element shorthand more usefully. (Even if SRFI 58 doesn't
specify the repeat-last feature, I'm sure some implementors would do it
that way.)

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

I have a better solution: If the "array" has rank 0, also omit the "#"!
After all, that's what the Scheme writer will do when printing a scalar.

This solution is more obvious if you use "#" instead of "x" for the
bound separators, e.g.:

    Two dimensions  #2#3((11 12 13) (21 22 23))
    One dimension   #3(1 2 3)
    No dimensions   1

Personally, I like the #2x3(...) syntax better; these examples are just
to show how the general pattern applies to the degenerate case.

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

I don't think the reader/writer/programmer interface needs to support an
array syntax for 0-rank "arrays," however. Indeed, I suspect that it
shouldn't, because it just introduces a "noise" token that can obfuscate
data but provide no real information.
--
Bradd W. Szonye
http://www.szonye.com/bradd