Issue: CONDITION-RESTARTS (Version 1)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri, 17 Mar 89 13:58 EST
    From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>

    The proposal doesn't compensate for the mistake of having
    disassociated restarts from context in the first place.

    All restarts should have associated with them a real predicate
    (not just a screwy wired-in (lambda (c) (eq c associated-condition)))
    In general the applicability of a restart depends on the dynamic
    environment in which it invoked as well as that in which it
    was established.

You're absolutely right.  In all the hoopla I had forgotten about this.
I think it's quite reasonable to have some convenient syntax for the
common case where the predicate is to test for a particular condition
object, but the underlying primitives should allow an arbitrary
predicate.  RESTART-BIND needs to be enhanced with a :TEST argument,
which is a predicate function that COMPUTE-RESTARTS calls.

    All restarting forms should require a condition argument (-not- NIL.)

I disagree with this, because it does make sense to restart a program
in response to some situation other than the signalling of a condition.

    Why on earth do ABORT, USE-VALUE, etc still exist?

I don't know either.

    The business about COPY-CONDITION is completely confused.

I agree with this.  The argument against resignalling a condition
is wrong; there is no confusion of identity if a condition is signalled,
this results in some transfer of control, and then the same condition
object, representing the same situation that is still happening, is
signalled again.  There is also no harm in a system keeping a particular
pre-created condition object around and using that same object every
time it signals a particular condition, so long as it keeps its restarts
straight.  Since it is the program that signals a condition that
establishes restarts bound to that particular condition, it knows what
it is doing, and if it knows that it doesn't establish any restarts
that are associated to the particular condition object, it knows there
is no harm in reusing the condition object.

    I don't care for the syntax, though it isn't worse than
    that of the rest of the condition system.

I don't like the syntax in the version that got mailed to X3J13, which
I don't think was really ready for mailing.  I had some alternate syntax
proposals, but I don't much like them either.

Here is what I would suggest doing to the proposal to make it ready
for X3J13:

  1. Define that it is an error for SIGNAL to be called on a condition
     more than once.

  2. Introduce a function COPY-CONDITION

Remove items 1 and 2.
 
Add a :TEST argument to RESTART-BIND.
Add a :TEST argument to RESTART-CASE.

  3. Introduce a macro WITH-CONDITION-RESTARTS

If we can't think of a better syntax for this, leave it out.  It can
always be done, awkwardly, by first making the condition object and
binding it to a variable, then doing a RESTART-CASE with :TEST predicates
that check for the condition being that one and with the expression
just being a call to SIGNAL of that condition.

  4. Extend COMPUTE-RESTARTS, FIND-RESTART, ABORT, CONTINUE, USE-VALUE,
     and STORE-VALUE to permit an optional condition object as an argument.

OK.

  5. Add two new macros SIGNAL-WITH-RESTARTS and ERROR-WITH-RESTARTS:

Same comment as #3.

  6. Define that Common Lisp macros such as CHECK-TYPE, which are defined
     to signal and to make restarts available, use the equivalent of
     WITH-CONDITION-RESTARTS to associate the conditions they signal with
     the defined restarts, so that users can make reliable tests not only
     for the restarts being available, but also for them being available
     for the right reasons.

OK (except don't use the name WITH-CONDITION-RESTARTS).