KMP's proposal

[David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>]

    Date: Sun, 7 Jul 1985  19:11 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

There seems to have been a disappointingly small amount of discussion of KMP's
proposal, unless some of the mail isn't getting to me.  I think I got two messages
 from Scott Fahlman, two from Mary Fontana, and one that I sent myself.

    ....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.

I wouldn't take that SIGNAL form too seriously; I think it mostly reflects
Kent's dislike of keywords.  While he may well be right, at this point I think
consistency with the rest of Common Lisp is more important.

Incidentally, in my proposal analogous to KMP's (from long long ago) I think
that the arglist to SIGNAL (and SIGNAL-CASE, ERROR, CERROR, and WARN) was
allowed to be an arbitrary arglist, defined by DEFINE-SIMPLE-CONDITION, rather
than being forced to be &KEY; the advantage to this is increased brevity for
conditions that have a small number of parameters, or whose parameters consist
entirely of a format-string and arguments formatted by that string.

    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.

You need both DEFINE-GLOBAL-HANDLER and UNDEFINE-GLOBAL-HANDLER (I think
CONDITION-SETQ is an unclear name).  We have these but don't have enough
experience with them yet to consider proposing them to go into a simple
stripped-down thing like KMP's.

    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.

I agree, except that the handlers established by any one condition-bind should
be tried in the order that they were written.