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

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

Ok, so I finally got caught up in my reading on this.  This is starting
to look pretty good, but I've bot a bunch of picky little comments about
how this should be projected ...

    Date: 5 Oct 88 00:57 PDT
    From: masinter.pa@Xerox.COM
    ...
    Issue:           ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
    ...
    in  most implementations of CL, an array X created with  and element-type 

"an element-type" ?

    ...
    This proposal suggests elimination of this distinction for the array types
    ARRAY,  SIMPLE-ARRAY, and VECTOR and their subtypes, by guaranteeing that 
    arrays constructed with a specific element-type satisfy the typep predicate
    with the derived array type-specifier, and by guaranteeing that subtypep 
    reflect the type equivalences defined by the behavior of make-array.

This paragraph doesn't belong in the problem description!

    Proposal: (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING)

    -- Introduce a function, UPGRADE-ARRAY-ELEMENT-TYPE of one argument, which 
       reveals how the given implementation treats a particular :element-type 
       argument to make-array.  Given a type-specifier <type1> as argument, it
       returns a maximal type-specifier <type2> such that <type2> is the
       actual specialized array element type used whenever <type1> is given as
       an :element-type argument to MAKE-ARRAY.   Note that 
	    (upgrade-array-element-type '<type>) = 
		(array-element-type (make-array 0 :element-type '<type>))
       for all type specifiers <type>.
   
I haven't decided how I feel about this part. You could do the same by
just saying ``Introduce the concept of an `upgraded' array-element-type...''
without actually providing the function that does the upgrading. But I guess
I think providing the function is harmless. Presumably it will be there anyway.

    ...
    Test cases:
    ...
    Thus, in each case, it should be true that:

I'd say "will happen to be true that", and emphasize that it's important
to know that this might happen -- but it's not something that should be 
particularly depended upon since obviously it will vary across implementations.

    ...
    That implies that the following set of tests should also be true:

      [B]
       (subtypep '(array <aet-x>) '(array <aet-y>))

This is a feature and should be encouraged.

       (subtypep '(array <aet-y>) '(array <aet-x>))

This happens by accident and might not always happen. Again, document it, but
make sure it's clear that this is only something to `guard against' and not
something to generally depend upon.

    Additionally, to show that un-equivalent type-specifiers that are upgraded
    to
    the same "element type" should be equivalent as element-type specifiers,
    the
    following type tests should be true:

      [C]
       (typep (make-array 0 :element-type '<aet-y>)
	       '(array <aet-x>))

Accidental,etc.

       (typep (make-array 0 :element-type '<aet-x>)
	       '(array <aet-y>))

Intentional,etc.