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

bear wrote:
>> At this point I have only one question:  For a rank-5
>> array, why #5A(...) instead of #A5(...)?

Per Bothner wrote:
> Maybe #A5 is marginally better, but I think compatibility with the
> prior art of Common Lisp argues for #5A.  That's not an overwheming
> argument, but (I think) tips the scales in favor of #5A.

Putting the rank first is likely to cause confusion for PLT users. PLT
Scheme has a shorthand notation for vectors with repeated elements:
#N(<E0>...<Ei>) is shorthand for a vector N elements long, with <Ei>
repeated as many times as necessary to produce N total elements. For
example, #5(0 1) is shorthand for #(0 1 1 1 1). Likewise, #N() is
shorthand for a vector of N zeroes; #5() is shorthand for #(0 0 0 0 0).

It'd be confusing to mix #5(...) and #5A(...) syntax: Only a single
character distinguishes between "a vector of five /elements/" and "an
array of five /ranks/." I'd expect users to occasionally mistype and
misread the dimensions.

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.

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.

> 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. The Scheme writer should never produce it, and I suspect that
very few human writers would ever use it. Even if you did want to
support it, I think it'd be reasonable to require a separator (space)
between the #A... token and the scalar.

>> I'm thinking about parsers here, where it's easier on everybody if
>> tokens differ as soon as possible.

> A (non-human) parser handles either just fine - except
> for the degenerate rank-0 case.

I don't think that's true for dialects (like PLT Scheme) that already
use #N... syntax for something else.
Bradd W. Szonye