# Re: SRFI-10 syntax vs. #nA syntax

This page is part of the web mail archives of SRFI 58 from before July 7th, 2015. The new archives for SRFI 58 contain all messages, not just those from before July 7th, 2015.

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