[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: firstname.lastname@example.org, Fahlman@C.CS.CMU.EDU
- Subject: Error Signalling
- From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
- Date: Fri, 27 Jun 86 15:55 EDT
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: The message of 27 Jun 86 11:20 EDT from mike@ALLEGHENY.SCRC.Symbolics.COM
Date: Fri, 27 Jun 86 10:20 EST
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.
It "is an error" to do
(let ((array (make-array 5 :element-type '(unsigned-byte 13))))
(setf (aref array 4) (ash 1 15)))
but it would be damn inefficient to REQUIRE all implementations to
support every single possibility. In this case, there are a gazillion
array types, but only a limitted number that can be implemented. In the
symbolics implementation, the above make-array returns an array that is
capable of storing 16 bit "bytes" because we "happen" to have an array
type that stores such things with less overhead than a general
I think changing "is an error" in all cases to "signals an error" would
violate the /Portability/ motivation on page 1 of the Silver Bible.
I think we (or the standards committee) have to carefully at all the "is
an error" and decide if it should be "signals an error". Many of us
agree number of argument checking should be signalled unless safety is
completely turned off, and that even then implementations are encouraged
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