* 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