Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)

[masinter.pa@Xerox.COM]

I'll rephrase my statement:

The benefit of UPGRADE-ARRAY-ELEMENT-TYPE--namely, that it doesn'tCONS
while the simple portable definition does--seems very small; I don't think
it outweighs the costs of adding it to the existing language. If
UPGRADE-ARRAY-ELEMENT-TYPE were already part of Common Lisp, I don't I
probably would not vote to take it out, even though it seems of limited
utility. Since it isn't in the language, I vote against adding it.

I also think that UPGRADE-ARRAY-ELEMENT-TYPE is strictly less useful than
ARRAY-DIMENSION and ARRAY-TOTAL-SIZE and that a first-principle argument
would be made against it. UPGRADE-ARRAY-ELEMENT-TYPE answers only a
hypothetical issue, viz: what *would* the type of this array be if I *were*
to upgrade it.

As I think about it, I'm not sure why we rule out the possibility that the
upgrading of arrays might happen differently for different arrays: for
example, I might have an algorithm that "upgraded" all simple
non-adjustable arrays with ARRAY-TOTAL-SIZE less than 2 to ELEMENT-TYPE T,
but be more strict about larger arrays.  The major part of the proposal
("Change the meaning of (TYPEP <x> '(ARRAY <type>)), where <type> is not
*, to be true if and only if <x> is an array that could be the result of
giving <type> as the :element-type argument to MAKE-ARRAY.") could be kept,
and the part that talks about upgrading (Clarify that "upgrading" implies a
movement upwards in the type- hierarchy lattice.) would just have to be
recast in terms of a specific array. 

This is counter to the part that says "Clarify that upgrading an array
element-type is independent of any 
    other property of arrays, such as rank, adjustability, fill-pointers, 
    displacement etc."

but I wonder now if that is a clarification -- is it a Change? -- and if it
is necessary.