Lynn Quam quam@ai.sri.com writes:
Is there any chance that SLIME:RESTART-FRAME will be implemented for CMUCL? I guess I do not know the limitations of the CMUCL stack frames and whether this is possible.
I think this would be quite a bit of work. Some random thought about the topic:
To restart the frame, we have to restore the dynamic environment for that frame. This is IMO the main problem. The dynamic environment consists basically of all the stack pointers (control stack, binding stack, alien/number stack, eval stack), current catch block, and current unwind-protect block. AFAIK, it is currently only possible to determine the control stack pointer, catch block and unwind-protect block. The other information is "there" in some way, because it is needed to implement THROW, but unfortunately, it is not easy accessible.
One way to make it accessible, would be to add some bits to the debug-info. E.g., we could record how many special bindings/alien slots a frame has and use that to compute the binding stack pointer in the calling frame.
A simpler, but less efficient, possibility would be to insert CATCH forms for those frames that should be restartable. CMUCL saves the dynamic environment at each CATCH and to restore dynamic environment, we could then just throw to that tag. Saving and restoring all those stack pointers is probably a bit expensive and so this whole approach has only limited utility. SBCL does something like this for (debug 3).
Yet another idea, would be to introduce a special kind of frame for dynamic bindings, catch, unwind-protect, with-alien etc. Adding the extra debug-info to those frames would then be relatively easy. I think Lispworks does something like this.
The next problem are the assembler routines to actually unwind the stacks, execute unwind-protect blocks, undo special bindings etc. This is probably not very difficult, because it is already done by THROW, but it is platform dependent.
Another (minor) problem are the arguments for the frame, because arguments are often no longer available. It is probably good enough to ask the user in this case.
Interesting stuff, but I doubt that it's worth to bother.
Helmut.