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

Re: #\a octothorpe syntax vs SRFI 10

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.



On Sun, 26 Dec 2004, Aubrey Jaffer wrote:

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

Need it be so succinct as to add eleven new octothorpe reader macros,
each dispatching further for the large number of different types of
arrays?  It would be much simpler, I think, and it would not lose much
brevity, to use SRFI 10; indeed, SRFI 10 was designed in response to
this issue as it arose in SRFI 4.

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

Sorry, I was not sufficiently clear there.  I meant to specify that the
rank defaults to 1, like #Axxx(...) in the current proposal.

>  | 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.
> 
>  | [...]
> 
> 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?

Perhaps I'm confused, but I don't see much difference between my usage
of symbols -- which exist only at read-time, never at run-time, unlike
nil and the EOF object -- and your usage of the suffixes of the new #A
syntax.  Could you elaborate on how my proposal is any worse in that
respect than yours?

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

This works for SRFI 47, but not necessarily this SRFI: one cannot
define one's own aliases for existing array types in the reader syntax.

>                                                         But explicitly
> complete descriptions for numeric types are rather long:
> 
> [...long list...]
> 
> 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.

I'm not suggesting names so long that they induce tedium in typists,
but rather names somewhat longer than are excessively obscure, such as
INTEGER-U16, COMPLEX-64, BIT, et cetera.  Furthermore, the single-
character mnemonics are derived from English, and there is certainly
the possibility that their names would begin with different initial
letters in other languages; however, everything in Scheme is from
English anyway, so I see nothing wrong with using English words for
array element type names.

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

For very fundamental primitives such as CAR & CDR that are frequently
used, and where the ability to stack them is convenient (in the case of
CAR & CDR, not, for example, HEAD & TAIL or FIRST & REST), this is 
quite reasonable; however, arrays are much less fundamental to Scheme,
and, even if one wishes to debate that, literal arrays are much less
frequently written than CAR & CDR.  A better analogue would be
ARRAY-REF, but I haven't seen any objections to that as opposed to
AREF, and I much prefer ARRAY-REF rather than AREF.

Regarding prefixes for radices & exactness: I still dislike them, but
numbers are so concisely expressed anyway that they would bloat their
significance in a literal number to expand the prefixes for radices &
exactness.  On the other hand, literal arrays' contents will usually be
much larger than just the initial characters denoting the element type,
so the length of the prefix is no more unnecessarily significant if
increased slightly.

Let me also point out here that much of Scheme's naming conventions and
lexemes originated from T.  In T, there was no built-in facility for
multi-dimensional arrays, but there were still object representation
names used by Orbit's representation analyzer and for the C & Pascal
FFIs.  These were named semi-verbosely, as I suggest above; e.g., the
representation descriptor of unsigned, sixteen-bit integers was named
REP/INTEGER-16-U.  Many of the names in T were intended to be long
enough to be understandable and not obscure, but not so long as to be
excessive; this has tended to hold in Scheme as well.  I think it would
be good to preserve that in the array element type names as well.

>  | 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:

Thanks.  That is much better.

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

Insignificant point: I think it would probably be a bit better to
follow that call to MAKE-ARRAY with code to initialize the new array.