Proposal #1

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

In general I favor the idea of defining the OPTIMIZE SAFETY declaration
to actually mean something, instead of leaving it totally vague.  However,
I have two complaints about this proposal which lead me to vote against it.

(1) The proposal means very little in the absence of any specifics about
which errors fall into which categories.  If the proposal is nothing
more than "If SAFETY = 0, implementations should not pay as much
attention to error checking as they would otherwise", how is this
different from what CLtL already says on page 160?  I don't think it's
necessary or useful to adopt this proposal in its current form; instead
there should be proposals that specific errors are to be detected or not
detected at specific settings of the safety switch.

(2) If we are going to classify exceptions to the language more
precisely, it is important that we separate the two types of exceptions
that are now amalgamated into "is an error".  One is errors that are
illegal in all Common Lisp dialects, but are considered too expensive
for some or all implementations to detect.  The other is loopholes that
are provided to allow some Common Lisp dialects to make extensions.

On the issue of how many levels there should be, mentioned by at least
Steele and Plummer, I suggest that an implementation that requires
additional levels should relax the requirement that the quantity be
of type (MEMBER 0 1 2 3), and instead use (NUMBER 0 3) or perhaps
(NUMBER * *), i.e. (AND NUMBER (NOT COMPLEX)).  The Common Lisp
specification should suggest this as an implementation technique.
Quantities outside of (MEMBER 0 1 2 3) could not be meaningful
in a portable program, so I don't think that it's necessary to require
all implementations to accept arbitrary noncomplex numbers here.