[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: Thu, 26 Jun 1986 23:14 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
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.
I'd say this is a non-spec. It should be possible for an implementation
to detect ALL errors. To say something is an error, but to not
require the implementation to detect it is to make it impossible for
programmers to debug code (unless you like hex core dumps...)
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.
As far as I'm concerned, this is the only reasonable position to
take. In general, I think the phrase "is an error" in CLtL should be
interpreted as "signals an error unless action is taken to ignore the
condition through declarations." I don't see any difficulty in implementation
here for Gold Hill.
3. Sitting on the fence: The conditions stated in option 2 are not
required in the spec, but they are "recommended".
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
I assume you mean option 2.
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.
Gold Hill Computers