[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

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

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/