Re: Debugging plans

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <address@hidden> writes:

    Marius> 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.

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

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

I completely agree, and note that there is already efficient support
in the code (with (debug-enable 'breakpoints)) for breaking where the
source properties so indicate.  (But nothing in the reader currently
sets the relevant source property.)

Trouble is, to work well (i.e. ergonomically), this mechanism requires
cooperation from the IDE as well (Emacs?), and I'd rather limit my
work for the moment to Guile on its own.  As you say, the general
approach is appropriate for some kinds of condition, and can easily be
combined with the more efficient approach once that is working.

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

I don't quite see the need here for full continuations.  I think that
everything in this list can be done equally well with a debug-obj or
just a stack, can't it?

Currently, at the point where a trap handler is called, the evaluator
creates either a debug-obj (if "cheaptraps" is enabled!) or a
continuation, and passes that to the handler.  But the slightly
strange thing is that calling the continuation is equivalent to simply
returning from the trap handler, hence do you really need the full
continuation?

Regards,
        Neil