[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
- From: Jon L White <jonl@lucid.com>
- Date: Sun, 1 Jan 89 21:40:16 PST
- Cc: pierson%mist@MULTIMAX.ARPA, cl-cleanup@sail.stanford.edu
- In-reply-to: David A. Moon's message of Fri, 30 Dec 88 17:43 EST <19881230224313.0.MOON@EUPHRATES.SCRC.Symbolics.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).
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.
-- JonL --