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 http://www.szonye.com/bradd