[slime-devel] Restartable frames

[Terje Norderhaug]

On Mar 22, 2010, at 11:26 AM, Helmut Eller wrote:
> * 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?

I don't think that would be neither useful nor feasible.

>> 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. [...]
>
>> 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?

-- Terje Norderhaug
   terje at in-progress.com