[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: Tue, 16 Jul 85 20:18 EDT
- Cc: Mary <Fontana%CSL60%ti-csl.csnet@CSNET-RELAY.ARPA>, cl-error-handling@SU-AI.ARPA
- In-reply-to: <FAHLMAN.12127358403.BABYL@CMU-CS-C.ARPA>
Date: Tue, 16 Jul 1985 00:49 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Now, in response to Mary Fontana's comments:
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.
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.
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.