Error-ology

[Steven <Handerson@CMU-CS-C.ARPA>]

Your letter seems to suggest this: Whether a condition (event) is @i(errorful)
depends upon the particular code being executed, as well as the lexical and
dynamic environment.  I think this is all we really need to say.  A program
being @i(in error) is a different thing entirely, although it is likely that
one grossly in error will eventually come to an errorful event.

Actually, I guess there is more.  One way a program can be in error is not to
handle a given condition.  If conditions are globally named and dynamically
scoped, a handler for a condition in one program segment may inadvertantly
handle the same condition in another segment.  The solution to this - some
means of explicitly manipulating the conditions associated with a function -
would probably lead to a better condition system, but it might also lead to
some language other than CL.  I still think it would be a mistake to not think
about this.

The set of conditions an implementation (or CL) has is chosen on the basis of
what events will cause unpredictable or inconsistent (in the sense of math, the
CL manual, etc) results.  The condition handling mechanism provides a way that
programs can recover from such events by providing their own interpretation of
what to do next.  For instance, short-floats do not overflow into long floats
because of the change in precision; some application may decide to remember the
precision itself, ignore the precision, etc.  I doubt many handlers will be
comlpicated, but if so, it would be nice if handlers could be filed away (for
instance, were normal functions).

Also, the distinction between an error's occurrence and detection is an
important one.  In general, you can't detect an error itself (except through
varying degrees of code analysis), only some errorful consequence.  This may
actually be important if we have to talk about (asynchronous?) errors in "jobs"
given to slave processes - the "error" might be in the master.

-- Steve