SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYSCommon Lisp provides many useful operations on lists and vectors which don't apply to arrays.
For example, one can FILL a vector with 0's, but not an array. One can REPLACE the contents of one vector with another, but one can't do this for arrays. One can verify that EVERY element of a vector has some property, but one can't do this for arrays. And so on.
The programmer who wishes to use arrays instead of vectors must give up most of the useful tools CLtL provides for manipulating sequences, even though there is no intuitive reason why operations like FILL, REPLACE, and EVERY shouldn't work on arrays.
Modify the definition of COERCE to allow the coercion of an array to a vector and vice versa. In keeping with p51 of CLtL, it should be an error if the result type has a different number of elements than the object being coerced.
Extend the definitions of sequence functions that either return their argument sequences, return sequences which are the same shape as their argument, or return non-sequences so that they also allow arrays iff their action is conceptually independent of the shape of the array. The affected functions are COUNT, SOME, EVERY, NOTANY, NOTEVERY, FILL, REPLACE, SUBSTITUTE, NSUBSTITUTE, and MAP.
Expressly forbid arrays as arguments to other sequence functions. These other functions are LENGTH, ELT, FIND, POSITION, REDUCE, SEARCH, MISMATCH, REVERSE, NREVERSE, SORT, MAP, SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES.
Since displaced arrays are already part of Common Lisp, the cost of the proposed changes would be very low.
If the change is not adopted, Common Lisp programmers who wish to use arrays will have two choices. Either they must write nested DO loops every time they want to perform an array operation equivalent to FILL, REPLACE, etc., or else they can build displaced vectors by hand and pass them to the sequence functions when necessary.
This proposal extends certain sequence functions in some interesting ways without committing us to a theory of how arrays and sequences relate that everyone may not be happy with right now.
The members of the Cleanup committee expressed interest in the ideas behind this proposal but weren't sure they could accept it in the proposed form. A rewrite to separate some of the issues more clearly was solicited. Rees suggested this subset of Tourtezky's proposal might be interesting.
Note that the function REDUCE is in a gray area. Many of its uses are not position-dependent, but some are. The same argument might be made about FIND. If people felt strongly, these too could be extended either by fudging the conservative rule or by explicit special case(s), but they have been omitted to be conservative.