Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)

[Jim McDonald <jlm@lucid.com>]

I'm disturbed by the consensus that seems to have formed around the
issue of upgrading array types.  In particular, I'd like someone to
point out why you can't simply require 

 (equal (array-element-type (make-array n :element-type x))
        x)

for all legal types x.

As far as I can tell, all you have to do is store x in the header
information of the array, for later retrieval whenever type issues
must be resolved.  

Since the internal implementation type y may differ from x,
UPGRADE-ARRAY-ELEMENT-TYPE becomes a merely informative routine that
users can employ to understand the efficiency with with their code is
implemented.  I can think of no other valid reason for a user to care
about the internal representation, with the possible exception of
interfacing to foreign code. 

In particular, any code that attempts to put objects of type y into an
array declared with type x is guaranteed to lose for some
implementation unless x and y are equivalent types.  This should be
reflected in signalled errors when safety is high.  If someone wants
to put 213 into an array, then they had better have created it with an
element-type that is a super-type of (integer 213 213).
(unsigned-byte 8) will work, (unsigned-byte 5) will not.

I.e., with safety 3, setf should type check against the declared, not
the internal, type.  With safety 1 or 2, it might check against the
internal type (presumably a cheaper test).

This is extremely simple to understand and to implement.  I think any
alternative to what I am presenting here adds enough complexity and
non-portability to the language to require a very solid and explicit 
justification.

  jlm