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

[masinter.pa@Xerox.COM]

I don't think we're connecting.  Consider:

Implementation A has a funny upgrade strategy.
Implementation B has a regular upgrade strategy.
(My suggestion:) The standard allows implementations to have both funny and
regular upgrade strategies, i.e., it does not constrain implementations.

A portable program calls MAKE-ARRAY with some ELEMENT-TYPE arguments, and
uses those *same* element-types in declarations and programs.

Implementation B, which only allows regular upgrade strategy, can use
reasonable compiler optimizations; it can assume "there are no variations
beyond the ones it 'knows' about." 

Implementation A, which employs a funny upgrade strategy, cannot use those
same compiler optimizations. Maybe it has compiler optimizations of its
own. Maybe it has special AREEF hardware. 

In any case, the fact that the standard ALLOWS implementation A to have a
funny upgrade strategy does not make it impossible for implementation B to
use reasonable compiler optimizations.

Does it?

The line of inquiry is not moot due to the type separateness of strings and
bit-vectors; all it says is that upgrade strategies have to do it in such a
way as to not cross those lines.

Also, the character committee's proposal includes making some modifications
to STRING such that STRING means any vector whose element type is SUBTYPEP
to CHARACTER, and allowing more specialized strings. I think that the
interaction of that proposal and this issue should be examined carefully.