Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 3)

[Jon L White <edsel!jonl@labrea.stanford.edu>]

I intend to put some more work in on this proposal later today (Friday)
which will, among other things, incorporate some of your suggestion; but 
others of your comments I'm not sure what to do with.


re: To my mind the proposal never quite says explicitly what it's proposing.
    It speaks in terms of modifications to the document rather than features 
    of the language.  

Of the several parts of the proposal, two go like this:

  -- Introduce a function UPGRADE-ARRAY-ELEMENT-TYPE, which will reveal how
     a particular :element-type argument to make-array will be treated.
     Semantically, this would be equivalent to:
       (defun upgrade-array-element-type (element-type)
         (array-element-type (make-array 0 :element-type element-type)))
     . . . 
  -- Change TYPEP (and SUBTYPEP) so that `(typep x '(array ,aet)) is true
     if and only if `(typep x '(array ,(upgrade-array-element-type aet)))
     is true.   

I think those are specific enough, as proposals.  The discussion section,
which you say you didn't read, contained further ramifications;  much of
that would cover what you want to add.  The remaining three parts of
the proposal are indeed concerned with documentation, since I think that
is one of the fundamental problems here -- CLtL has the particular mis-
features of the "warp" built-in at numerous places, and they will have to 
be removed.


re:  The subtype relations among type specifiers (ARRAY type1) and 
     (ARRAY type2) are as follows:  For all values of type1 and type2, 
     (ARRAY type1) and (ARRAY type2) are either equivalent or disjoint.

Yea, I *think* this is true under the unify-upgrading proposal; but isn't
it true under the status quo also?   see the "warp" statement at the 
bottom of CLtL p45, and the disjointness statement on p46: "Now
(array character) is not a subset of (array t); the two sets are in fact
disjoint because ..."   What I thought the interesting question would be 
is that found in the discussion section of the proposal, near:

    Since this proposal contains the implication:
      `(array ,aet-x)  is-type-equivalent-to  `(array ,aet-y)
      ==> 
       ,aet-x  is-type-equivalent-to  ,aet-y
    then the question naturally arises "Does the reverse implication hold?"  

The answer I came up with is no. Perhaps you should go read that after all.


re: ... COMPLEX should be mentioned in the body of the
    proposal as a subject for a necessary companion proposal. 

Ok, why not.  It seems clear to me that most implementations will have a
totally different kind of upgrading for COMPLEX's than for ARRAY's, and
that's part of the reason I don't want to mix the two together right now.


re: You need to list explicitly the type specifiers that are affected by
    this proposal, so no one overlooks one.

I did, but in the problem statement part:

     . . . i.e., those [type-specifiers] that are subtypes  of ARRAY.
      This implicitly includes SIMPLE-ARRAY and VECTOR.

What more were you thinking of?  simply noting that forms like
(ARRAY <type>) and (VECTOR <type> 3) and (SIMPLE-ARRAY <type> (* * *)) 
are all subtypes of ARRAY?


One more question I have for you [apparently no one else is reading
these more complicated proposals?].  Do you find the notation 
`(array ,aet-y) distracting?  I notice that in your comments you use
(ARRAY type-y) instead.  Is the form `(array ,aet-y) bad enough
to warrant complete substitution?  At least one of my early readers
here at lucid didn't like it.

I think it would be real good if we could get some knowledgeable, but
"uncontaminated", reader to go over this proposal now.  Or maybe Version 4.



-- JonL --