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

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri, 07 Oct 88 19:06:32 EDT
    From: Dan L. Pierson <pierson%mist@multimax.ARPA>

	This is inconsistent with current practice in that implementations are
	currently permitted to ignore type declarations altogether -- not just
	for array but for anything.
    
    Sorry 'bout that.  Would you be happy if it was changed to specify
    that implementations which pay attention to type declarations must
    treat references to array elements as strictly as any other declared
    type?

Not really. Any non-conforming implementation could claim to be in the
set of those who don't completely pay attention to declarations.
It's not that I oppose the sentiment. I just don't want to spin our wheels
to no good end. I don't think it takes a formal vote of X3J13 for us to
ask Kathy to add an implementation note to the declartions section that
reminds people that implementations can do such checking and suggests that
they do so where feasible.

To an extent, I think this is the sort of thing that it's appropriate (or
at least -- given all the other things we already have cooking -- necessary)
to let ``market pressure'' take care of.

    More globally, with the new error terminology we're going to have to
    decide whether implementations will still be permitted to ignore type
    declarations for interpreted and unoptimized code.  Since these cases
    can no longer be "is an error", they've got to become either "should
    be signalled", "undefined", or "unspecified".  I favor "should be an
    error" because type checking can be a powerful debugging tool and some
    current users appear to expect it to work as such, look at the CLX
    sources for example.

Strictly, there's no decision called for.
"undefined" is the same as "is an error".

I think what you mean to say is now that we have more terms, we might
want to incompatibly change the language so that more things take
advantage of that new terminology.

Put another way, CLtL is unambiguous about the "undefinedness" about
a lot of things, but that lack of ambiguity may not have been intended.
Insofar as numerous such cases are arguably mistakes, and more precise
language may have sometimes been intended (or since been seen to have
been a good idea), it's now time to think about fixing those situations.

If that's what you mean, I agree. But such things are going to be
very expensive at times to do, and we should be honest about the costs
so that implementors can know what they're buying into (or what to
vote against if the cost is prohibitive).