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

[Dan L. Pierson <pierson@mist.encore.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).
    
Sorry, but that's exactly the opposite of what I meant.  If I declare
an array, FOO, to be (SIGNED-BYTE 5), within the scope of that
definition I'm saying that expect references to that array to be
equivalent to:
    (THE (SIGNED-BYTE 5) (AREF FOO X))
No matter what the array was upgraded to.  Upgrading should  refer to the
array's physical layout and overall type, but it should not license
the FOO below to be a different type from (AREF BAR X) in FROB.

    (DEFUN FROB (FOO BAR)
       (DECLARE (TYPE (SIGNED-BYTE 5) FOO)
		(TYPE (ARRAY (SIGNED-BYTE 5)) BAR))
       ...
    )

    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.
    
Actually, your name got put in support because of an early message of
yours (which I finally found) in the ARRAY-ELEMENT-TYPE-SEMANTICS
discussion.  I'll be happy to remove your name if we now disagree.

As I've said before, I support a strict type checking mode for all
Common Lisp compilers.  However I now suspect that it's too late (and
maybe too experimental) to get in this version of the standard.  I
said I'd write up a proposal for it at the cleanup meeting last
October, but was later talked out of doing so.