KMP's proposal

["Scott E. Fahlman" <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.")

-- Scott