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.
| 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)