[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
- To: Dave.Touretzky@C.CS.CMU.EDU, CL-Cleanup@SAIL.STANFORD.EDU
- Subject: Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
- From: Masinter.pa@Xerox.COM
- Date: 19 Nov 87 13:38 PST
- In-reply-to: Dave.Touretzky@C.CS.CMU.EDU's message of Mon, 16 Nov 87 01:57:08 EST
Integers are not floating point numbers, although all of the functions
that work on floating point numbers can easily be extended to work on
integers in all the cases that make sense. Just because there is a way
of converting an array into a sequence doesn't mean that an array *is* a
Frankly, most other programming dialects that I am aware of coerce an
array into a vector by treating
#2A((A B C) (D E F) (G H I)) coerces to #(#(A B C) #(D E F) #(G H I)),
i.e., a vector arrays. Since there are multiple reasonable views of an
array as a sequence, I'm not happy with extending COERCE: COERCE should
be left for those cases where there is a unique "natural" injection.
I believe the drift on this proposal (also in discussions in Denver) is
that we should leave the ARRAY and SEQUENCE types alone, but change the
section title of "sequence function" to talk about a set of generic
functions that work on types LIST, VECTOR, and, for some of them, ARRAY.
Post-CLOS, we might also be able to document how users can define how
these functions work for their own types, too.
This would be a gentle upward compatible change which gives us most of
what we want, without doing too much violence to our sensibilities.