[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposal #1 - minor revision
- To: Common-Lisp@SU-AI.ARPA
- Subject: Proposal #1 - minor revision
- From: Masinter.pa@Xerox.COM
- Date: Mon, 14 Jul 1986 01:48:00 -0000
There was an error in my message -- I deleted the wrong sentence in Case
1. Here's what I meant to say:
- - - - - - - - - - - -
The expressions of doubt that Scott alluded to in his message is
summarized as follows. There are two situations: before there is an
error system that defines what "signals an error" means, and after. In
one, the distinction between class #2 and class #3 is moot. In the
other, the distinction violates an important principle of Common Lisp
declarations, namely, that they do not affect the results of correct
Until there is a standard for what "signals an error" means,
1) There is no semantic difference between "signals an error"
and "is an error" other than the vague statement that
"signals an error" will somehow "enter the debugger".
However, no correct program can depend upon any
condition signalling an error since the action of the
debugger is undefined.
2) Implementors are already encouraged to signal errors
in all "is an error" situation, and, presumably, SAFETY
declarations might well have some effect on it.
In this situation, the distinction between class #2 and class #3 errors
After there is an error system which defines what "signals an error"
1) "signals an error" has program language semantics, and
2) "correct" programs can rely on "signals an error" to
catch the error and process it in some standard way, and
3) declarations about safety shouldn't affect the operation
of correct programs.
In this situation, any error in class #2 would violate principle (3).