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

Re: #\a octothorpe syntax vs SRFI 10

Bradd wrote:
>> Also, brackets have one major shortcoming (which the current SRFI 58
>> proposal shares): Since dimensions are inferred from the bracket
>> contents, there's no way to represent arrays with a 0 dimension.
>> For example, you can use SRFI 47 functions to create a 0x2x3 array:
>> (MAKE-ARRAY '#() 0 2 3).  However, there's no "natural" external
>> representation for this array using brackets.  Currently, SRFI 58
>> suffers from the same problem: Its syntax specifies rank explicitly
>> but infers shape from the list decomposition.  What should the Scheme
>> writer use to represent that array?  Is it an error?

Aubrey Jaffer wrote:
> The updated SRFI-58 provides clarification about rank 0 ....

That's not the same thing as a rank with a zero dimension. In the
current syntax, you'd write a 0x2x3 array as #3A(), I think. How does
(ARRAY-RANK '#3A()) figure out that it's 0x2x3 instead of, say, 0x5x7?

However, since you mention it, SRFI 47 does not support rank-0 arrays as
written; MAKE-ARRAY requires at least one bound. SRFI 58 does not yet
correct this.

>> I think #,(ARRAY ...) syntax is appropriate for some arrays.  It would
>> permit a good, general notation for arbitrary arrays, based on the
>> MAKE-ARRAY function of SRFI 47.
>>     #,(ARRAY <prototype> (<dimensions>) (<element>...)opt)
>> For example (using the common "brackets = parens" syntax for clarity):
>>     #,(ARRAY #() (2 2) [[a b] [c d]])    ; 2x2 heterogeneous array
>>     #,(ARRAY (AS32) (2 2) [[1 2] [3 4]]) ; 2x2 array of 32-bit fixnums

> With brackets this looks good.  Without brackets it would be a mess.

It's about the same as the new ARRAY procedure, just as a reader syntax.
However, I later realized that SRFI 10 isn't so good for arrays, since
it's incompatible with quasiquotation. (The SRFI 10 syntax doesn't
support it, and I think it may be incompatible with quasiquotation on a
conceptual level.)

>> Specifying the dimensions also permits a convenient shorthand for
>> repetitive arrays: If there aren't enough elements for a dimension,
>> simply repeat the last element.  For example, #100(1) is shorthand
>> for #(1 1 1 1 ... 1) in MzScheme, and #100() is shorthand for #(0 0
>> ... 0).  A similar array syntax could use the analogous #A100x100()
>> to get a very large zero matrix.

> What is the utility of an immutable large zero matrix?  That shorthand
> could be useful in calls to the ARRAY (or LIST->ARRAY) procedure, but
> for literal arrays it is wasted.

It's more useful for writer/reader syntax than it is for literal arrays,
but it's still handy for the occasional zero matrix and for arrays that
vary only in the first few elements. Not a big deal, just noting that
there's prior art here.
Bradd W. Szonye