Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS

[Jon L White <edsel!jonl@labrea.stanford.edu>]

You raise a number of good points here.  I'm going to reply to several
of them out-of-order, to do the "easier" ones first.


re: In the discussion section, "In short, no one would not want to 
    gain portability at the expense of limiting the language . . .
    Take out a "not."

Yes, several persons here at Lucid noted the typo too.  Take out a "not".



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.



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?



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.  . . . This could seriously impact the adoption cost.  I think I 
    have mentioned this before; do I have to drag out all the other comments 
    I made last time this issue came up?

Yes, I think this assumption about independence is right. I don't remember
your bringing out any such discussion on cl-cleanup before; the only note
I can find is just a statement of this same assumption sent out to the
common-lisp mailing list:

    Date: Fri, 11 Mar 88 16:02 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    Subject: the array type mess....
    To: Ram@C.CS.CMU.EDU
    Cc: Jon L White <edsel!jonl@LABREA.STANFORD.EDU>,
	    common-lisp@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
    In-Reply-To: <RAM.12365298662.BABYL@>
    . . . 
    An interesting comment on all this is that we are implicitly assuming
    that an implementation's spectrum of specialized array types is independent
    of the size, number of dimensions, indirectness, or adjustability of the
    array.  This seems unlikely to be true of all implementations.  I don't
    know how to fix this deficiency.

    Someone should write this up in Cleanup form and thus give us all
    a chance to think about it more deeply.

But the grim file reaper seems to have put on temporarily inaccessible
back-up tape my cl-cleanp archives prior to Mar 4, 1988.  So I may have
just missed all the commentary about it before.

On the other hand, if this assumption is violated, the 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.  
I've heard that Symbolics users frequently do this in order to run
sequence-like functions over 2-dimensional arrays.



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?  



-- JonL --