Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS

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

    Date: Sat, 21 May 88 06:05:42 PDT
    From: Jon L White <edsel!jonl@labrea.stanford.edu>

    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
	COMPLEX?

    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
UPGRADE-COMPLEX-ELEMENT-TYPE?

    re: Your proposal assumes without stating it explicitly that
	  (array-element-type (make-array dimensions :element-type element-type
						     options...))
	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
	it.

    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, 
    "setf-function-vs-macro").   

    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.