Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES

[Dan L. Pierson <pierson@mist.encore.com>]

    I don't have any record of this issue being discussed.  If I'm
    coming in late, please ignore and forgive me.
    
There seemed to be some sentiment that it was just a minor editorial
correction, flavored with a touch of "but doesn't CLtL already require
this?".  My carelessness about the error handling unfortunately
attracted more attention than the issue itself.

        Date: Fri, 07 Oct 88 17:19:22 EDT
        From: Dan L. Pierson <pierson%mist@multimax.ARPA>
    
        Issue:         DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
    
        References:    Array type specifiers, pp. 45-46
    
        Related issues: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, DECLARE-TYPE-FREE
    
    I don't think this has any actual interactions with the issue
    ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, since
    DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES is about ARRAY type specifiers for
    declaration, while ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS is about ARRAY type
    specifiers for discrimination.
    
When I first raised this issue, JonL responded that he agreed (though
he may now have changed his mind), but that
ARRAY-TYPE-ELEMENT-SEMANTICS wasn't the right issue.  On the other
hand, I'll be happy to remove the references if you want.

        Proposal (DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE):
    
        Within the scope of an array type declaration, all references to array
        elements are assumed to satisfy the exact declared element type.  
    
    That's reasonable.  However, this is not a CLARIFICATION but a CHANGE,
    since CLtL p.46 seems to be quite clear that the current meaning of such
    a TYPE declaration is that the array elements satisfy the implementation
    element type (what JonL calls the upgraded type), not the exact declared
    element type.  Since your proposed new definition is more restrictive,
    some portable programs that used to be correct may now be in error, hence
    this is an incompatible CHANGE.  I think I'd vote for it anyway unless
    someone argues that there is a significant impact on users.
    
Hmm, JonL seemed to think it was a CLARIFICATION, however your
arguments are convincing and this CHANGE is exactly what I want.  It
seems to me that anything else violates the clearly stated intent of
the user.

    								      An
        implementation should signal an error if this is ever violated.  
    
    That's not reasonable.  The status quo for type declarations is that
    a violation "is an error".  Changing it to "signals an error" is likely to
    meet enormous resistance especially from stock hardware implementations,
    and I think even changing it to "signals an error at the highest SAFETY
    setting" would meet significant resistance.
    
Well, it certainly met significant controversy.  I got a number of
strongly partisan responses on both sides of the question.  Note that
the phrase in question is "should signal an error", which implies only
the interpreter and the safest compiler setting.  The big oversight
here is that I carelessly introduced this part of the proposal as a
minor part of a different issue.  While I would very much like to see
a compilation (and maybe interpretation) mode which check all type
declarations for violation and signals errors, I've become convinced
that this is something a few vendors should implement before it is
standardized.  For one thing there's the question of when to check: on
-every- operation, on operations that would otherwise do a typecase?
The former may imply too much overhead for aanyone, the latter might
not catch many of the cases of this proposal.