[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: cl-cleanup@SAIL.STANFORD.EDU
- Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 24 May 88 16:39 EDT
- In-reply-to: <8805211305.AA08320@bhopal.lucid.com>
Date: Sat, 21 May 88 06:05:42 PDT
From: Jon L White <firstname.lastname@example.org>
re: I don't understand the justification for introducing the function
UPGRADE-ARRAY-ELEMENT-TYPE. There are plenty of other type operators
missing from Common Lisp, why put in just this one?
Because of the prevalence of user confusion about "upgrading" in arrays;
this gives him a reasonable query mechanism for a very common problem. It
also, quite likely, reflects a functionality that each implementation will
have to provide for itself anyway.
I don't buy either of those arguments. That's just my personal opinion.
re: You don't list what type specifiers it applies to. I assume you mean
to include SIMPLE-ARRAY and VECTOR in addition to ARRAY. What about
I didn't think that explicit mention of SIMPLE-ARRAY and VECTOR was
necessary, as they are subtypes of ARRAY. However, it can't hurt to
put in the one sentence clarification. I did not mean COMPLEX; I only
meant to cover arrays. Perhaps COMPLEX could be "swept under the same
rug"; do you think it is a good idea to do so?
I'd like to see COMPLEX included, too. I think it would be a mistake to
fix only half the problem, especially if later someone fixes the rest of
the problem in an incompatible way. Are you going to introduce
re: Your proposal assumes without stating it explicitly that
(array-element-type (make-array dimensions :element-type element-type
is independent of the values of dimensions and options. I believe this
to be true of most implementations, but see nothing in CLtL that requires
Yes, I think this assumption about independence is right.
....I'd be curious
to know how an implementation can do, say, displacement of a vector to
a multi-dimensional array with conformal element type, and vice-versa.
There could be more element types for displaced arrays than for simple
arrays. I am not going to argue that it's important that Common Lisp
continue to allow that, especially if no implementations depending on it
are discovered. I'm reasonably sure that all Symbolics implementations
have the same menu of element types for all kinds of arrays, but I don't
know that much about any other implementations.
In any case, assumptions like this must be stated explicitly, especially
for their effect on the cost of adopting the proposal.
re: The proposal is much too long and contains too many digressions.
There are two proposals here, you know; the verbal discussion in Palo Alto
on March 13 suggested we would need two (and maybe this was a first?). I
have had commentary on it from folks at Lucid, but I note that CL-CLEANUP
has been effectively moribund for the six weeks prior to the submission of
this proposal. So I don't think the lack of other public replies means it
is any more difficult to comprehend than the other long proposals (such as,
On the other hand, I agree that is is unfortunately long; I don't easily see
what can be deleted without opening up loopholes for someone to argue against.
Do you have some specific suggestions as to what could be elided without
inviting more criticism?
I think the second proposal should be deleted before it leaves the Cleanup
committee. It probably makes sense to leave it in for now. I think some of
the digressions about interesting krinkles and so forth aren't needed even now,
but certainly should be deleted before it leaves the Cleanup committee. I
think all but the first paragraph of the problem description could be deleted
or moved into the discussion section at the end.