[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
- To: Masinter.pa@Xerox.COM
- Subject: Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
- From: Pedersen.pa@Xerox.COM
- Date: 19 Nov 87 14:24 PST
- Cc: Dave.Touretzky@C.CS.CMU.EDU, CL-Cleanup@SAIL.STANFORD.EDU
- In-reply-to: Masinter.pa's message of 19 Nov 87 13:38 PST
I agree that trying to stuff something similar to APL "reshape" and APL
"ravel" into coerce would most likely lead to confusion rather than
clarification. However, the "ravel" operation is a quite useful one --
and would be a nice complement to the proposed AREF1. "Ravel" is easily
written in terms of existing primitives, but its major value is in
abbreviating a frequent operation. E.G.
(defun ravel (array)
(typecase array
(vector array)
(array
(make-array (array-total-size array) :element-type
(array-element-type array) :displaced-to array))
(other
(error "Not an array: ~s" array)))
)
I guess it is worth insisting that the vector returned from "ravel"
share storage with the argument array.
Supposing one had "ravel", then I see no driving need for any of the
extensions outlined in "SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)".
Perhaps someone would care to enlighten me on this point. Is the
argument that distributing array coercion throughout some (but not all)
sequence functions is likely to be more efficient -- more esthetic ?
Larry's argument that the sequence functions form a paradigm that should
be extendable to include arbitrary structures is interesting, but I fail
to see how "SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)" makes this
any easier or any harder. Surely it is sufficient to make all the
sequence functions generalizable.
J.P.