Error Signalling

[David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>]

    Date: Fri, 27 Jun 86 10:20 EST
    From: mike@a

	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
can-hold-anything array.

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
to check.

	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.
    
	-- Scott
    
    ...mike beckerle
    Gold Hill Computers