| Date: Tue, 4 Jan 2005 13:42:08 -0800
 | From: "Bradd W. Szonye" <xxxxxx@szonye.com>
 |
 | 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.