[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
- Subject: KMP's proposal
- From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
- Date: Thu, 18 Jul 1985 15:46 EDT
- Cc: cl-error-handling@SU-AI.ARPA
- In-reply-to: Msg of 18 Jul 1985 15:29-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
- Sender: 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.
That's all the mail I've seen as well. Perhaps the problem with FTP-ing
the proposal from CMUC deterred people from commenting, but that should
be fixed now. If anyone has any strong reservations about this kind of
approach (as opposed to the small details), you'd better speak up now,
or else the three or four of us who are interested in this issue will
wind up settling it among ourselves. (Maybe that wouldn't be so bad.)
Once we've got a proposl that those of us on this list like, we should
send it to the full Common Lisp list, and if nobody objects then, we can
take it as a probationary standard, I think.
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.
I'd prefer to go with all-keywords for uniformity, but since the user
would have to know what a given condition expects in any event, I could
live with Moon's proposal.
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.
That name change is fine with me. I think we'd better put these in
right from the start, since it looks to me like certain applications
will have to go through confusing gyrations if we leave them out.
I agree, except that the handlers established by any one condition-bind should
be tried in the order that they were written.
Sounds OK to me. We might want to warn users that unless they are doing
something odd, they will want to put the more specific handlers before the
more general ones when they write a condition-bind.
Has anyone got time to write up a revised proposl including the changes
suggested by Fonatana and Moon, suitable for incorporation into the
manual? I will do this if nobody else wants to, but I'll be off the net
starting next Saturday until August 4, so I can't work on it before then.