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

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

    Date: 11 Jan 89 14:47 PST
    From: masinter.pa@Xerox.COM

    ....
    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,

Actually you couldn't do that, because Common Lisp mandates the separate
existence of strings and bit-vectors.  But we get the idea.

    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,

No, because you would have to say what the other arguments to MAKE-ARRAY were.

If you can prove that the statement I just said is false, then I will change
my mind and agree with you, since it would considerably simplify the proposal.
I spent some time just now unsuccessfully trying to prove that the statement
is true.  The place to think about is SUBTYPEP.

    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.

You're probably right that it is a change, although I think JonL was
unable to find any current practice that it contradicts.