[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 16:05 EDT
- Cc: cl-error-handling@SU-AI.ARPA
- In-reply-to: Msg of 16 Jul 1985 20:18-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
- Sender: FAHLMAN@CMU-CS-C.ARPA
2. I think we need restart handlers to set up proceed options which do
a non-local transfer of control.
Is a special piece of machinery really needed for this? Couldn't this
be handled easily by Condition-case, with one or more of the clauses
being a throw to some appropriate outer catch? Or am I missing something?
It's not the same as condition-case; it's more like a variant of signal-case.
The point is to provide ways of recovering from the condition that are
implemented not by the place in the program that detected the condition, but
instead by some outer part of the program -- some dynamic caller of the place
that detected the condition. This is pragmatically useful and also is
important from a software engineering point of view, since it lets you hide
from the outside world the modularity of a program it's calling; you can hide
the fact that the detection of a condition and the means of recovering from
that condition may be in separate sub-modules. I think this could fit in
fairly smoothly, it just involves separating the two underlying parts of
signal-case: the actual signalling and the set of proceed-types.
Yeah, that was a thinko on my part. I meant SIGNAL-CASE and not
CONDITION-CASE. If something else is really useful, I'd like to see a
specific proposal for what that would look like. It sounds to me like
the hair-to-value ratio is pretty high here, but maybe I'm imagining a
less elegant mechanism than Moon has in mind.
3. Class hierarchy of conditions as well as proceed options should be
available. This was discussed in Kent's memo on exception handling.
Can you supply an example where this is needed? The simpler we keep
this, the easier it is going to be to come up with something usable.
Classification of conditions is already in KMP's proposal (see
DEFINE-SIMPLE-CONDITION). Some examples can be found in Reference Guide to
Symbolics-Lisp, pp.482-484,533. I'm not sure about classification of proceed
options; KMP didn't propose that in his recent stripped-down proposal.
OK, if the machinery in KMP's DEFINE-SIMPLE-CONDITION is all that is
being proposed, that seems reasonable enough.
4. The common lisp functions ERROR and CERROR should include a
signal-name (condition-type) argument.
I agree. It's not obvious to me where such an argument can be inserted
in a compatible way, however.
The place to insert the argument has been provided and the way has been made
straight. Remember a couple of years ago when I argued for a change to the
arguments of CERROR, and said that I would tell you the reason later? If the
first argument to ERROR, CERROR, or WARN (but not BREAK) is a symbol, instead
of the string that would normally be expected, then it is a condition name.
Is the signal-name arument meant to replace the error string, or just
push all the arguments back one place? If the former, then the text to
be printed comes from the condition definition and not from the ERROR
form itself? Seems reasonable. My first reaction was that it would be
confusing not to see the message text there where the error is being
signalled, but I guess that is inevitable if you want to be able to
redefine handlers for the various important error classes.
Do we require (and enforce) that the condition signalled by an ERROR or
CERROR call is in fact a subtype of ERROR? (I can see the text now: "An
Error-Condition-Not-Subtype-Of-Error error is signalled if the condition
signalled by a call to Error is not an Error.")