KMP's proposal

["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>]

Several months ago Kent M. Pitman sent out a proposal for a Common Lisp
error system that is more or less the Lisp Machine error system
converted so that it doesn't require flavors.  (KMP's system, or a
superset of it, could easily be implemented using flavors, but flavors
are not required.)  I was too busy at the time to pay much attention to
this proposal, but lately have come back to it, since we have begun to
feel the inadequacy of Spice Lisp's very primitive error system.  I
think that KMP's proposal, with perhaps a bit of minor polishing, is
just about what we need as the standard error system for Common Lisp.  I
would really like to decouple this issue from the object-oriented stuff,
while retaining enough of the object-oriented style that the people
already using a flavor-based error system will not have trouble adapting
to this standard.

If people want to look at this proposal, I have a copy of it on CMU-CS-C
as <fahlman>kmp-error.txt.  It should be possible to FTP this
anonymously from arpanet sites.

Since it is hard to evaluate and debug an error system just by reading
about it, let me suggest the following process:

1. We discuss this specific proposal to see if it is generally
acceptable and whether anyone can find major or minor problems with it.

2. If people generally agree that this is the way to go, we tentatively
adopt this as a standard.  This system should then be implemented in a
few Common Lisp systems and should be exposed to real users.

3. We do any necessary tuning of the specification based on this
experience, and then adopt a final version as a legitimate part of
Common Lisp.

I have some reservations or questions about three things in KMP's
proposal:

1. It disturbs me that the "keywords" used in the SIGNAL form are not
really keywords.  Maybe these should be real keywords (though the
variables bound in the handlers would be packaged symbols with the same
print name).  There is precedent for this in some other parts of Common
Lisp.

2. I'm not sure that having only Condition-Bind and no Condition-Setq is
right.  I agree that programmers should be encouraged to use
Condition-Bind most of the time, but there may be occasions when it is
much more convenient to be able to establish certain condition-handlers
globally.

3. KMP does not spell out the rules of inheritance for handlers.  I
suspect that the right thing to do is to first find any matching
handlers in the dynamically-innermost condition-bind and then to try
them in most-specific-first order.  Upon exhausting those options, we
would go to the next condition-bind out and try any matching handlers
there, and so on.  The point is that one condition-bind might establish
a lot of handlers for specific errors, and then inside that extent there
might be a condition-bind that binds only ERROR.  I think that a signal
coming from within that environment wants to first try the ERROR handler
rather than any of the more specific handlers from the outer context,
since the user was obviously trying to do something like an errset.

-- Scott