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


This looks good.

An obvious question that is going to arise is why did we define
rather than (CONCATENATE 'VECTOR array).  In researching this I note
that it's pretty hard to tell from CLtL whether the other sequence
coercions are required to allocate new storage, or are allowed to share
existing storage, when they don't just return the argument.  The word
"copy" is used in an off-hand remark, and I had always assumed without
thinking about it that COERCE was a copying operation, but CLtL never
actually says whether or not the result is allowed to share storage with
the argument, when they are not identical.

I imagine that unlike any other use of COERCE, our proposed
(COERCE array 'SEQUENCE) is -required- to share storage with the
argument, so that SETF of ELT may be used on the result, causing the
elements of the original argument to be affected.  If true, we certainly
should put in a sentence or two of rationale to forestall questions.
This should both explain that we did it this way not just for "efficiency",
but so the user could rely on side-effects propagating from the vector
back to the array, and also say something about the relation of this to
the vagueness of the other sequence coercions.

This raises the question, why is COERCE really in this proposal anyway?
It almost seems to be there only to support the remark at the end about
how the whole proposal could have been replaced with a proposal just to
extend COERCE, but we chose not to do that.  Maybe Dave T can comment on
the reasons for including COERCE.