KMP@MIT-MC

[Kent M Pitman <KMP @ MIT-MC>]

    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.

-kmp