[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Handerson @ CMU-CS-C
- Subject: KMP@MIT-MC
- From: Kent M Pitman <KMP @ MIT-MC>
- Date: 13 October 1984 19:24-EDT
- Cc: cl-error-handling @ SU-AI
- In-reply-to: Msg of Sat 13 Oct 1984 18:10 EDT from Steven <Handerson at CMU-CS-C.ARPA>
Date: Sat, 13 Oct 1984 18:10 EDT
From: Steven <Handerson at CMU-CS-C.ARPA>
... I'd like to suggest that before proposals are thrown around,
we start discussing just what an error or condition is, how the
two interact, and what are necessary vs. gratuitous aspects of a
condition system ...
I'd like to start even more slowly by just defining the terms
to be used in our discussions.
The CL manual uses the terms "error", "signal", and "handle". It does
not use the term "condition", but perhaps we should introduce that
distinction (as the LispM does). My experience with using the LispM
says that it is an important distinction to make.
In a manual put out by Symbolics entitled "Signalling and Handling
Conditions" they standardize on essentially the following terms (the
definitions of which I have mostly paraphrased here):
The term "event" refers to "something that happens" during the
execution of a program.
The term "condition" refers to a class of object which is associated
with the occurrence of a particular kind of event in a program.
The term "signal" refers to the action of reporting an event to other
parts of the program which may be interested.
The term "handle" refers to an action taken by some program as a
result of a signal.
The term "error" denotes a particular type of condition which is
associated with an event that has been detected by a program as not
part of its contract. When an error condition is signalled, the
program may not proceed without the condition having been handled
somehow. This implication is not necessarily true of all conditions--
only of error conditions.
I recommend that for our purposes the term "event" and the term
"condition" be merged and that both "something that happens" and the
object which represents that "something" be referred to as the
"condition". The rest of the terminology I recommend we adopt
essentially as I've described it here.
As mentioned in the manual (p428), CL contains primitives to signal
errors, but no primitives for handling them. One important function of
this discussion must be to identify the primitives we need.
Also, since the manual does not treat [non-error] conditions,
it follows that CL has no primitives for signalling such conditions.
We may also want to decide if there should be some mechanism for
treating such conditions.
Does anyone disagree with any of the above and want to propose
modifications or alternatives? First order of business should be to
standardize on as many terms as we can agree are useful so that we don't
end up talking across purposes.