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@in-progress.com