Re: #\a octothorpe syntax vs SRFI 10

[Aubrey Jaffer <agj@xxxxxxxxxxxx>]

 | From: campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx
 | Date: Thu, 23 Dec 2004 12:30:28 -0800 (PST)
 | 
 | I believe that this was brought up on the SRFI 47 mailing list, but
 | it seemed to have been ignored, as SRFI 47's array syntax was
 | removed and punted to this SRFI.  I therefore again propose to
 | change the array syntax to use SRFI 10's #,(constructor ...)
 | device, rather than introducing a multitude of new another new
 | octothorpe reader syntax characters for arrays.

Arrays are a fundamental data organizing paradigm from the origins of
computing; FORTRAN has arrays; APL has arrays.  I hope arrays will
become part of Scheme in R6RS.  For a construct which generalizes two
of Scheme's three aggregate data types, a succinct read-syntax does
not seem overly burdensome.

 | In particular, I suggest that it be:
 | 
 |   #,(ARRAY [<rank>] <type> <elements> ...)

Rank cannot be deduced from <element> nesting for heterogeneous
arrays.  I suggest that <rank> be required.

 | So, for example, the two-by-two array of unsigned 16-bit integers from
 | the document might be written as #,(ARRAY 2 u16 (0 1) (2 3)).
 | General object arrays' types would be OBJECT (so #(FOO 1 #T ())
 | could also be written #,(ARRAY OBJECT FOO 1 #T ())) and character
 | arrays' types would be CHAR (so "foo" could alternatively be
 | written #,(ARRAY CHAR #\f #\o #\o)).

This appears to introduce type symbols like U16 and CHAR which are not
part of srfi-47.  The prototype functions in srfi-47 return arrays.

 | For details on the rationale of this change, see the pre-finalization
 | (note 'pre!') discussion archive of SRFI 4 and the rationale section of
 | SRFI 10.

I am not opposed to also having SRFI-10 syntax for arrays.  This would
seem to require reserving a set of symbols for type specification,
which is an unschemely way of doing things.  Scheme goes to some
lengths to avoid using symbols as cookies; witness NULL? and
EOF-OBJECT?

 | (I'd also prefer that the names be longer & much more descriptive, like
 | UNSIGNED16 or BOOLEAN, but I suppose that's a little too late, now that
 | SRFI 47 has already been finalized & the incomprehensible abbreviations
 | of array types have been set into stone...)

SRFI-47 defines procedures to return prototype arrays.  Additional
procedures can be added to alias the abbreviated ones.  But explicitly
complete descriptions for numeric types are rather long:

ac64	inexact-double-precision-complex-array
ac32	inexact-single-precision-complex-array
ar64	inexact-double-precision-real-array
ar32	inexact-single-precision-real-array
as64	exact-64-bit-signed-integer-array
as32	exact-32-bit-signed-integer-array
as16	exact-16-bit-signed-integer-array
as8	exact-8-bit-signed-integer-array
au64	exact-64-bit-unsigned-integer-array
au32	exact-32-bit-unsigned-integer-array
au16	exact-16-bit-unsigned-integer-array
au8	exact-8-bit-unsigned-integer-array
string	char-array
at1	boolean-array
vector	object-array

These long names present more of a burden for the memories of
non-English-speakers than the short names, which are the same for
everyone.  There is Scheme precedent for abbreviated names in
identifiers like CADR an CDADAR and in the radix and exactness
prefixes #B, #O, #D, #X, #E, #I.

 | Also, one more  comment on the draft: it doesn't actually say, as far
 | as I can tell, anything about the actual syntax of arrays.  It just
 | gives an example & a reader.  This is a rather glaring omission.

Thanks for pointing this out.  I have replaced the example with:

 By list-decomposition is meant rank nestings of lists of the elements
 where the most nested list has length equal to the last dimension of
 the array and at top level has length equal to the first dimension of
 the array.

 A two-by-three array of unsigned 16-bit integers is written:

 #2au16((0 1 2) (3 5 4))

 This array could have been created by (make-array (Au16) 2 3).

 (array-dimensions #2au16((0 1 2) (3 5 4))) ==> (2 3)