[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
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
per@xxxxxxxxxxx   http://per.bothner.com/