SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

Comments on excerpts from version 3 of the proposal:

    Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE):

    1) Modify the definition of COERCE to allow the coercion of an array to
    a vector and vice versa. 

Coercion of a vector to an array doesn't make any sense, since a vector
is already an array.  I think what you must really mean here is to
generalize the first bullet on CLtL p.51 to say "any sequence or array
type can be converted to any other sequence or array type..." and to
add that this includes coercions that change the rank of an array and
coercions between lists and arrays of rank other than 1.  We have to
explain how array rank changes, and array dimension changes, renumber
the elements; basically row-major order, but a somewhat more verbose
explanation is probably appropriate.

			     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.

I don't see anything about number of elements on p.51 of CLtL.  I only
see a comment about type of elements.  Is this a separate cleanup proposal
to define whether (coerce "foo" '(vector * 2)) returns #(#\f #\o) or
signals an error?  What about (coerce "foo" '(vector * 4))?  I think that
should be dealt with in a separate proposal.  If you want current practice
input, both of these signal an error in Symbolics Common Lisp.

If it's clarified as I suggest, I would agree with this part.

    2) Modify the definition of MAKE-SEQUENCE to accept array descriptions
    as well as vector descriptions.

I disagree with this, but also I'm not sure what it says.  If it means
that MAKE-SEQUENCE should be able to return an array of rank other than 1,
I disagree, because I don't think we are proposing to extend the type
named SEQUENCE to include such arrays.  On the other hand, if it means
that (make-sequence '(array double-float 1) 5) should be valid, as far
as I can tell it is already valid.  If it's based on someone's idea
of the internal implementation of SUBSTITUTE, REVERSE, and MAP, doing
(MAKE-SEQUENCE (TYPE-OF argument) (LENGTH argument)), I think that's a
silly reason to change the language.

    3) Extend the definitions of sequence functions that either return their
    argument sequences or return non-sequences so that they also allow
    arrays. 

Again, say "of rank other than 1" since they already allow rank-1 arrays.

	    These functions should treat array arguments as vectors
    displaced to the array storage (in row-major format). The affected
    functions are LENGTH, ELT, COUNT, FIND, POSITION, SOME, EVERY, NOTANY,
    NOTEVERY, REDUCE, SEARCH, MISMATCH, FILL, REPLACE, NSUBSTITUTE,
    NREVERSE, SORT.

I agree with this.

    Extend the definitions of sequence functions whose result should be the
    same shape as but not necessarily EQ to some argument. These functions
    should deal with array arguments by returning an array of the same
    shape. The affected functions are SUBSTITUTE, REVERSE, and MAP.

I agree with this.

    Expressly forbid arrays as arguments to sequence functions that modify
    the number of elements in the array because the shape would be
    undefined. These functions are SUBSEQ, COPY-SEQ, CONCATENATE, MERGE,
    REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES.

Does the novel phrase "expressly forbid" mean that CLtL leaves this open to
extension ("is an error"), or that CLtL requires this to signal an error,
or does it mean something else?  I guess I prefer "is an error".

Conclusion: I support sending this to X3J13 but would like to see
the language of the proposal made crisper as suggested above.