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

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

In general, I agree with ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING,
however I have a few comments.

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.  I would summarize it as "The type specifier (ARRAY type)"
denotes the set of all arrays that can result from calling MAKE-ARRAY with
a :ELEMENT-TYPE argument of type.  The equivalence relations among type
specifiers (ARRAY type1) and (ARRAY type2) are implementation-dependent,
since they depend on whether the implementation has distinct
representations for arrays with the two element types.  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."
[I added that last sentence, since I didn't find your proposal clear on
SUBTYPEP.  Is my sentence what you intended to propose?]

I really don't think it's acceptable to leave COMPLEX out.  The declaration
versus discrimination distinction applies just as much to COMPLEX as to
ARRAY; at a minimum, COMPLEX should be mentioned in the body of the
proposal as a subject for a necessary companion proposal.  I think it would
be better to include the proposal for COMPLEX in this one; it's a
straightforward extension of the ARRAY proposal and will not complicate it.
The one sentence version is "The type specifier (COMPLEX type) denotes the
set of objects that can result from giving numbers of the specified type to
the function COMPLEX."  To that one should add the same comment about type
equivalence and subtypes as I made for arrays in the preceding paragraph.

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

I really don't think the UPGRADE-ARRAY-ELEMENT-TYPE function is necessary.
Everything you explain in terms of it can be explained in terms of
ARRAY-ELEMENT-TYPE.

I'm not sure I believe your claim that the cost to implementors and cost to
users are small.  This is an incompatible change, admittedly in an obscure
area.  Symbolics makes much heavier use of types than most other users of
Common Lisp that I am aware of, particularly in presentation types, a
compatible extension of Common Lisp types, and Statice types, another
compatible extension of Common Lisp types.  I would not care to assert that
this proposal will have no impact in those areas, I'd have to do some study
first.  The cost to implementors to change TYPEP and SUBTYPEP themselves is
clearly small, but the cost to keep other things in the implementation
consistent with the change might not be small.  Also the claim that no
users could depend on the current workings of Common Lisp in this area
because some users are confused is poor reasoning, and appears naive about
users.  I would not care to assert that there are no users out there who
depend on the present behavior.

I think it would be better to admit that it is an incompatible change
and argue that the decrease in confusion justifies the cost.

The discussion section was real long, so I didn't read it.