Issue: CONDITION-RESTARTS (Version 1)

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

    Date: Wed, 15 Feb 89 15:03 EST
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    Here's some questions/comments that need to be factored into the
    next draft on this issue...

I don't have any record of anyone ever answering this message.
I reckoned that if someone answered it you might be more motivated
to come up with this next draft.

    1. Moon has suggested that COPY-CONDITION is not necessary.  Does anyone
       disagree? I am willing to remove it, but doing so will make this
       proposal less `compatible.' I don't care much one way or the other, but
       I don't want to be accused of being `callous' toward people who do care.
       If this committee will back me up on the removal of that function and
       the resulting compatibility problems that could in principle (though
       perhaps not in practice) come up, then I'll make the change. Opinions?

I still believe COPY-CONDITION is not necessary. 

    2. Moon has also asked that the syntax to SIGNAL-WITH-RESTARTS and 
       ERROR-WITH-RESTARTS be:
	SIGNAL-WITH-RESTARTS signal-argument-list &rest restart-clauses
	ERROR-WITH-RESTARTS  signal-argument-list &rest restart-clauses
       so that you would write
	(SIGNAL-WITH-RESTARTS ('FOOD-COLOR-ERROR :FOOD 'LETTUCE :COLOR 'PINK)
	  ...restart clauses...)
       rather than
	(SIGNAL-WITH-RESTARTS (MAKE-CONDITION 'FOOD-COLOR-ERROR
				:FOOD 'LETTUCE :COLOR 'PINK)
	  ...restart clauses...)
       If you wanted to use MAKE-CONDITION, you would then write:
	(SIGNAL-WITH-RESTARTS ((MAKE-CONDITION 'FOOD-COLOR-ERROR
				 :FOOD 'LETTUCE :COLOR 'PINK))
	  ...restart clauses...)
       The advantage of what he proposes is that you could write
	(SIGNAL-WITH-RESTARTS ("Bad ~S color" 'FOOD)
	  ...restart clauses...)
       and a condition object would be created implicitly as with SIGNAL. A
       possible disadvantage is that
	(SIGNAL-WITH-RESTARTS (FOO BAR BAZ)
	  ...restart clauses...)
       might look to someone like the FOO in (FOO BAR BAZ) named a function
       rather than a variable. Does anyone else have an opinion on this?

I still believe my suggestion would be an improvement, but I think
even better would be 

  (WITH-CONDITION-RESTARTS signal-form &rest restart-clauses)

where signal-form must be an invocation of SIGNAL, ERROR, WARN, or
perhaps a few others, or a macro that expands into such an invocation.
WITH-CONDITION-RESTARTS must signal an error at all levels of safety if
it does not recognize the signal-form.  This is "weird" because it uses
a form for something other than evaluation (but not unprecedented; this
is exactly what SETF does).  The advantage is that it just nests with an
existing syntax instead of inventing a new, awkward syntax.

Note that I stole the "good name" WITH-CONDITION-RESTARTS for this
commonly used syntax.  The less commonly used primitive that just sets
up the restarts without signalling doesn't need as good a name.

    3. Rees has suggested that the syntax for WITH-CONDITION-RESTARTS should be 
	WITH-CONDITION-RESTARTS condition-form restarts-form &BODY forms
       rather than
	WITH-CONDITION-RESTARTS (condition-form restarts-form) &BODY forms
       which it is now. Does anyone else have an opinion?

This is probably a good idea.  I'd probably name this one
WITH-CONDITION-RESTARTS-INTERNAL.  But are we sure that this operation
needs to be named in the standard at all?

    4. Rees has asked for advice about how the condition/restart association
       might be implemented -- is some kind of alist structure held by a
       special variable what was intended, or ought the condition have a
       restarts slot. He and I talked a little about this and eventually he
       agreed that it's pretty obvious that the relation should be externally
       represented. It's important that the association not be done by a slot
       in the condition because if you carry around the condition object after
       you're done signalling, you don't want it to contain useless and/or
       misleading information about restarts that no longer exist. I'll probably
       add some notes to this effect when I generate the next draft.
       This doesn't really require comment, unless someone seriously disagrees.


Agreed.