[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
- To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
- From: Dan L. Pierson <email@example.com>
- Date: Tue, 03 Jan 89 11:56:16 EST
- Cc: firstname.lastname@example.org
- In-reply-to: Your message of Fri, 30 Dec 88 17:43:00 -0500. <19881230224313.0.MOON@EUPHRATES.SCRC.Symbolics.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>
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
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.
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
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.