[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: common-lisp@SU-AI.ARPA
- Subject: Error Signalling
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Fri, 27 Jun 1986 03:14:00 -0000
- In-reply-to: Msg of 26 Jun 1986 00:56-EDT from Glenn S. Burke <GSB at AI.AI.MIT.EDU>
- Sender: FAHLMAN@C.CS.CMU.EDU
We don't need anything like *RSET. Common Lisp provides the user with
an appropriate way of specifying whether speed or error checking is
preferred: the OPTIMIZE declaration. Most good implementations detect
and signal argument count, argument type, array bounds, and similar
errors, except when the user has indicated that speed is valued more
than safety (some use SPEED > SAFETY, others use SAFETY = 0). Actually,
that statement is somewhat backwards: signalling these errors
appropriately is one of my criteria for a "good implementation".
The question we should address is what we should say about such errors
in the standard for Common Lisp. There are three options:
1. The status quo: each of these things "is an error", but it is
entirely up to the implementor whether and under what circumstances to
detect and signal these errors.
2. The rigorous solution: For errors of the types described above, it is
REQUIRED that implementations signal an error in interpreted code. It
is also required that these errors be signalled in compiled code unless
(optimize (safety 0)) is in effect at compile time.
3. Sitting on the fence: The conditions stated in option 2 are not
required in the spec, but they are "recommended".
I think that 2, the rigorous solution, is clearly the best approach for
standardization and for portability of code. However, we should adopt
this only if there is a fairly strong consensus in its favor, and only
if it doesn't make too much toruble for existing implementations. If
those conditions are not met, we should go with the status quo. I'm
undecided about option 3. Should a spec get into the recommendation
business? In many cases where we can't actually require things,
recommendations may help to keep divergence to a minimum.
We will soon need to make a formal decision about what goes into the
spec. I'd like to know what people think of these three options --
please try to be brief. Also, if you represent an implementation group,
please indicate whether the requirement in option 1 would make real
trouble for you, regardless of whether you favor it. The question is
not whether you could install this by next Tuesday, but whether it would
be a problem to meet this tightened requirement in a release nine months
or a year from now.