[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: CONDITION-RESTARTS (Version 1)
- To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Issue: CONDITION-RESTARTS (Version 1)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 9 Mar 89 14:25 EST
- Cc: CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: <890215150320.0.KMP@BOBOLINK.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
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)
(SIGNAL-WITH-RESTARTS (MAKE-CONDITION 'FOOD-COLOR-ERROR
:FOOD 'LETTUCE :COLOR 'PINK)
If you wanted to use MAKE-CONDITION, you would then write:
(SIGNAL-WITH-RESTARTS ((MAKE-CONDITION 'FOOD-COLOR-ERROR
:FOOD 'LETTUCE :COLOR 'PINK))
The advantage of what he proposes is that you could write
(SIGNAL-WITH-RESTARTS ("Bad ~S color" 'FOOD)
and a condition object would be created implicitly as with SIGNAL. A
possible disadvantage is that
(SIGNAL-WITH-RESTARTS (FOO BAR BAZ)
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
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.