[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
- Subject: KMP's proposal
- From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
- Date: Thu, 18 Jul 85 15:29 EDT
- Cc: cl-error-handling@SU-AI.ARPA
- In-reply-to: <FAHLMAN.12125199827.BABYL@CMU-CS-C.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
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
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
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.