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

[masinter.pa@Xerox.COM]

JonL, I was not suggesting a requirement that implementors would have to
upgrade different arrays differently. Why would Lucid oppose allowing other
implementors to take a different implementation strategy? Certainly your
compiler optimizations could continue to work based on your assertions
about your own array implementation types.

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

You know what the other arguments to MAKE-ARRAY are by looking at <x>.
Imagine:

Implementation A upgrades integer ranges to (SIGNED-BYTE n) for n a power
of 2 up to 32, and then T.
Implementation B upgrades integer ranges to (SIGNED-BYTE 32) and then to T.
Implementation C upgrades simple small (say, less than total-size 2) arrays
like B, and other arrays like A.  

You can implement (C:TYPEP object type) by (if (simple-small-p object)
(b:typep object type) (a:typep object type)). I.e., TYPEP need not merely
be implemented by ARRAYP + a test on ARRAY-ELEMENT-TYPE.