[slime-devel] Restartable frames

[Terje Norderhaug]

On Mar 22, 2010, at 1:59 PM, Helmut Eller wrote:
> * Terje Norderhaug [2010-03-22 20:14+0100] writes:
>
>>>> This has usability implications as swank clients cannot adapt to
>>>> whether a frame certainly is restartable, might possibly be
>>>> restartable, or definitely isn't restartable.
>>>
>>> There's no definive answer to this question without unwinding the
>>> stack
>>> and executing unwind-protected handlers.
>>
>> There is at least a definite answer to the question when the back-end
>> does not implement a restart-frame function. When the frame
>> definitely cannot be restarted, the swank client should obviously not
>> present the user with the option to restart the frame.
>>
>> Are you saying a back-end never can determine without actual
>> execution that a frame on the stack for practical purposes is
>> restartable?
>
> Yes.

If so, frame-restartable-p should return NIL only when the frame  
definitely cannot be restarted and T when the frame possibly can be  
restarted. This makes the current default frame-restartable-p, which  
always returns NIL, unusable as default for back-ends that have a  
working restart-frame.

Either back-ends that implement restart-frame also need to implement  
frame-restartable-p, or the default frame-restartable-p should return  
T for back-ends that provide a restart-frame function.

With this in place, the backtrace slimefun will more consistently  
inform the client whether a frame potentially can be restarted or  
definitely can't be restarted.

-- Terje Norderhaug
   terje at in-progress.com