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


I don't understand Fahlman's objection to calling arrays sequences.  We've
considered every sequence function in CLtL, and extended them to arrays in
all the cases that made sense, which is all cases except when the result
would be a sequence that could have a diferent number of elements than 
the input sequence.  Given this step, we should either admit that arrays
are sequences, or else rename the sequence functions to ``sequence or array

Let me restate the basic intuition one more time.  A sequence is like a string
of beads.  If you stretch it out straight you have a list or vector.  If you
fold it up in various ways using COERCE or MAP, you have an n-dimensional array
which you can access with AREF, which is not a sequence function.  The beads
still sit on the string in the same order, and the sequence functions still
give the same result no matter how you fold the string of beads.  This property
is guaranteed by the existing commitment in CLtL to storing array elements in
row-major order.

Calling arrays sequences only affects the description of the sequence
functions; it doesn't affect array functions, string functions, etc.  If Scott
overlooked this point, it might explain his intuition that the ramifications of
this change would be hard to predict or control.

Another natural consequence of my modified proposal would be to allow MAP
to return multi-dimensional arrays, since COERCE can do it.

Suppose Aij is a 3x3 array.  We can apply operation F to every element of the
array, and get back a new array of the same shape, by writing

  (MAP '(ARRAY * (3 3)) #'F Aij)

Note: if we just specify ARRAY for the result type, we should get back a nine
element vector instead of a 3x3 array.  CLtL should be modified to indicate
that the result of MAP is a list or vector as long as the shortest input
sequence, *except* when a different length or shape is explicitly specified.

-- Dave