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


Okay, here's a cleaned up description of coercion and sequences, which should

1.  The term "sequence" includes not only lists and vectors, but also arrays,
with the understanding that array elements are accessed in row-major order.
This guarantees that functions like LENGTH, ELT, FIND, POSITION, etc. will
behave the same way on a coerced sequence (of the same length) as on the
original sequence.

2.  COERCE can convert from any type of sequence to any other.  It is undefined
whether the result of a coercion shares structure with the original sequence.

3.  If a sequence is coerced to a vector or array with an explicitly-specified
length N not equal to the length of the input sequence, M, then:
  a) the result of the coercion must be of length exactly N, as requested
  b) if N < M, the extra elements in the input sequence are ignored
  c) if N > M, the initial values of the extra elements in the result 
       sequence are undefined


 This extension fits naturally with the generalization of sequence functions to
operate on arrays.  It changes the nature of arrays in the language by making
content more important than structure.  Sequences can be converted to different
shapes, maintaining the same content, and all the sequence functions will
continue to return the same results.

 The idea that the result of coercing an array to a vector should share
structure with the original was never part of my original proposal; it was
suggested as an alternative to the proposed extensions to the sequence
functions.  I don't like it, as it forces COERCE to copy in some cases (e.g.,
string --> list) and explicitly not copy in others.  Type coercion is unrelated
to the copy vs. share structure debate.  Therefore we should leave it undefined
whether COERCE copies or not, except to continue the convention in CLtL that if
the input is already of the specified type, it will be returned without

-- Dave