Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES

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

    Date: Sun, 1 Jan 89 21:40:16 PST
    From: Jon L White <jonl@lucid.com>

    I seem to have no record of past mail on this issue, but I remember at
    one time arguing against it since it tended to contradict the agreement
    in ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS -- namely (1) that we wouldn't
    distinguish between "for declaration" and "for discrimination", and
    (2) that the original source-code element-type specifier may be "upgraded"
    so that for all intents an purposes you can't recover the "exact declared 
    element type".  But if all that Dan wanted to say was that the array
    references were assumed to satisfy the *upgrade* of the declared type,
    then there would be no problem (with that part).

I basically agree with you, but would like to point out one thing that I
hadn't thought of until I read your mail just now.  Since a portable
program cannot know what the upgraded element type is, it must not
assume that all implementations have some objects that are members of
the upgraded element type but not members of the exact declared type.
This means that if it "is an error" for an array element not to be of
the upgraded type, it also "is an error" for an array element not to be
of the exact declared type; either way, a program that does that is not
portable.  So the only real problem with Pierson's proposal is its
proposed change of enforcement of type declarations from "is an error"
to "signals an error".

Now, if we make it "signals an error in the highest safety mode" then
we're back with the same problem: does it signal an error when you
violate the declared type, or only when you violate the upgraded type?
The former provides a more portable definition of when errors are
signalled, but violates the consistency of declaration with
discrimination.  The latter keeps declaration and descrimination
consistent, but means that there are some cases that "are an error" (or
at least are not portable) in lower safety settings, but fail to "signal
an error" in the highest safety setting.

    My name probably got put reference in this proposal because I have
    generally given support for the following notion: that there be at least
    one mode of operation (interpretation or compilation) in which all type
    information is rigidly checked.  I don't think Lucid would be that averse
    to some form of required error signaling in this case; but likely it
    wouldn't be in interpreted code --  rather, it most easily could be in
    code compiled under highest safety [because the interpreter currently 
    doesn't pay attention to type declarations].  Contrary to your suggestion, 
    I would have thought that Symbolics would offer more resistance to this 
    idea than would "stock hardware" implementatons, since many of the latter
    have already invested in a compiler cognizant of type declartions.

I was referring to the suggestion that type information be rigidly checked
in all modes, not just in the highest safety mode.  In fact it would not be
terribly difficult for Symbolics to check all type requirements, including
declarations, rather than just most implicit type requirements, in the
highest safety mode.  What priority this would have for implementation
relative to other things I can't say, but I do know that keeping track of
type declarations in the compiler would not be a major part of the work.
I believe it is a one-line change, actually.

It would be interesting to see the impact of a Lucid implementation where
debugging was easier in compiled code than in interpreted code.