[slime-devel] Restartable frames

[Helmut Eller]

* Terje Norderhaug [2010-03-22 18:20+0100] writes:

> On Mar 22, 2010, at 6:54 AM, Helmut Eller wrote:
>> * Terje Norderhaug [2010-03-21 20:39+0100] writes:
>>
>>> Six swank back-ends implement the RESTART-FRAME interface. Yet only
>>> two of these back-ends implements FRAME-RESTARTABLE-P, which is used
>>> by the BACKTRACE slimefun to identify whether a frame is restartable.
>>>
>>> Allegro and SBCL implement both restart-frame and frame-restartable-
>>> p. ABCL, CCL, CLISP and LispWorks only implement restart-frame.
>>
>> ABCL doesn't support it; the code is just a comment.  CCL only on PPC.
>> CLISP or LispWorks have no documented debugger API and without knowing
>> the internals it's hard to say anything other than "may or may not
>> work".
>
> Hence there are really three answers to the question of whether a  
> frame is restartable: "yes", "no" and "maybe". Yet the BACKTRACE  
> slimefun only allows FRAME-RESTARTABLE-P to return T or NIL:
>
> (ecase (frame-restartable-p frame)
>    ((nil) nil)
>    ((t) `((:restartable t))))
>
> I suggest BACKTRACE passes on the "maybe" semantics to the client,  
> for example by returning the :restartable if and only if it  
> definitely can be determined whether or not a frame is restartable.  
> As in:
>
> (ecase (frame-restartable-p frame)
>    ((nil) `((:restartable nil)))
>    ((t) `((:restartable t)))
>    (:maybe nil))

What next? A probability that it might work?

>>> For consistency, perhaps back-ends that implement restart-frame also
>>> could implement frame-restartable-p?
>>
>> They can but it shouldn't be required.  The default implementation  
>> seems
>> good enough to me.
>
> The default implementation of frame-restartable-p always returns NIL,  
> even for back-ends that implement restart-frame. The consequence is  
> that swank clients are unable to determine whether a frame definitely  
> cannot be restarted or whether the frame might be restarted.

Then implement the predicate for those backends if you know how to do
it.

> 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.

Helmut