On Fri, 31 Dec 2004, bear wrote:

> >What makes arrays so fundamental in syntax as to require a notation as
> >succinct as lists?  Lisp syntax is not defined in terms of arrays: the
> >literal array syntax is only a minor convenience.  There are many more
> >lists than arrays in a portion of code, typically.
>
>
> And that, I believe, is a problem.  Lispers often use lists where
> arrays would be more appropriate in terms of efficient access to
> data.  They do this, in part, because lisp handles lists so gracefully
> in its syntax and language primitives that it's easy to overlook
> arrays.  This comes about, I think, because in most lisps, list
> syntax is natural and array syntax is comparatively cumbersome.

This is an absurd straw man.  The fact that the syntax is defined in
terms of lists has nothing to do with the functionality of arrays
available.  Sure, lists occur in Lisp syntax more often: the syntax is
defined in terms of them.  Sure, there is probably less code that uses
arrays in Scheme than uses lists: SRFI 47 was fairly recent.  But to
conclude that the absence of a condensed array syntax has impeded the
development of array-related code is a ludicrous absurdity.  Even if
people were deterred by the absence of a standard array syntax, which I
think is still a ridiculous claim and which you must defend _much_ more
rigorously with than 'I believe that's a problem,' that might be simply
because there _hasn't_been_one_, be it condensed or readably verbose.

If you want there to be more comprehensive array processing libraries,
write them!  That is entirely orthogonal to the notation chosen for
literal arrays; I sincerely doubt whether an array library, similar in
scope to SRFI 1, would contain in its implementation any more literal
arrays than SRFI 1's reference implementation, ignoring arrays as the
first argument to MAKE-ARRAY.

> I would even support arrays-as-syntax replacing lists-as-syntax
> in several cases.  A 'switch' statement using an array to hold the
> cond clauses rather than a list would actually be easier to compile
> into an efficient binary-search or index-jump table, in addition
> to clarifying the surface syntax.

Easier than CASE how?  In either case you'd have to walk a sequence of
clauses and generate code for each one.  The surface syntax would be no
different from CASE, except that you'd use different delimiters for the
clauses or something -- which, hey, you could do anyway, were square
brackets to be made equivalent to parentheses! --.  This, too, is an
absurd straw man.