Re: Debugging plans

[Marius Vollmer]

Neil Jerram <address@hidden> writes:

> I think a nice general way of specifying a breakpoint is a procedure
> that gets the current stack and can decide, by examining that stack,
> whether to drop into the debugger, display some variable, etc.

Yes, that is general, and we should have such a possibility, but it is
also inefficient, I'm afraid.  You would need to stop at every
possible breakpoint and check all your conditions.

For a watch point or some other kind of `global' condition, this is
fine, but for a simple breakpoint at a certain place in the code, it
feels quite wasteful.

For that, I think having a way to splice a special breakpoint
instruction into the memoized code would be best.

On a more general note, I would approach the debugger design from
continuations, I think.  That is, once an exception like a unhandled
error, a breakpoint or a triggered watchpoint occurs, the debugger is
invoked with the continuation representing the stopped program.  The
debugger could then perform certain operations on that continuation,
like extracting information about its stack frames, evaluating
expressions in the environment where the program stopped, and single
stepping the continuation (which would yield a new continuation), etc.