This page is part of the web mail archives of SRFI 58 from before July 7th, 2015. The new archives for SRFI 58 are here. Eventually, the entire history will be moved there, including any new messages.
| Date: Tue, 4 Jan 2005 13:42:08 -0800 | From: "Bradd W. Szonye" <bradd+srfi@xxxxxxxxxx> | | bear 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? The updated SRFI-58 provides clarification about rank 0: Rank 0 arrays have one element; that element appears after the prefix (perhaps with intervening whitespace) with no additional parenthesis. ... Rank 0 arrays: #0a sym #0A:real-32 237.0 | > You wanted an extremely verbose syntax using srfi-10. It turned out | > that nobody else wanted it, based on aesthetic objections. | | 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. | #,(ARRAY #() (0 2 3)) ; zero-dimension array A 0 by 2 by 3 array would be #,(array #() (0 2 3) ()) A 2 by 3 by 0 array would be #,(array #() (2 3 0) ((() () ()) (() () ()))) | This allows the reader to use any SRFI 47 "prototype" function to | specify array types. Thus, if a Scheme implementation adds new array | types, they can simply add a new prototype generator. For example, an | implementation can extend both MAKE-ARRAY and the reader syntax to | support 36-bit integers simply by defining new "AS36" and "AU36" | prototype functions. | | (MAKE-ARRAY (AS36 0) 1 2) => #,(ARRAY (AS36) (1 2) [[0 0]]) SRFI-10 makes a point of applying its elements, not evaluating them. So defining AS36 does not implement it; one must re-register the SRFI-10 syntax. If your SRFI-10 function evaluates an argument, then it opens a trap door for mischief. | I don't think this is appropriate for hand-written, heterogeneous | arrays, however. For those, I prefer something much terser. The | proposed syntax is almost good enough; however, I would rather it | specify the array /dimensions/ rather than rank. That's more | consistent with existing extensions, like PLT's #n(...) syntax for | vectors. | | 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.