[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
- To: Jon L White <firstname.lastname@example.org>
- Subject: Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
- From: Dan L. Pierson <email@example.com>
- Date: Tue, 03 Jan 89 12:15:07 EST
- Cc: firstname.lastname@example.org
- In-reply-to: Your message of Sun, 01 Jan 89 21:40:16 -0800. <8901020540.AA21474@bhopal>
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
(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.