Re: What debugger breakpoint features would you like?

[Neil Jerram]

>>>>> "Keith" == Keith Wright <address@hidden> writes:

    >> From: Thien-Thi Nguyen <address@hidden>

    >> #f -- go interactive
    >> #t -- do step (or whatever)
    >> (pk ARGS...) -- emulate `pk' (display ARGS and value after evaluation)
    >> (warn TEST MSG . SUBST) -- TEST value (after evaluation),
    >> if true, emit MSG and use SUBST value
    >> positive number -- do step multiple times
    >> negative number -- do something else
    >> etc

    Keith> Let's skip the cryptic codes and just use symbols that do what
    Keith> they say:

    Keith>    #f -- do the normal thing
    Keith>    'break -- go interactive
    Keith>    '(display ARGS ...) -- What the fsck is `pk'?
    Keith>    'step -- do step
    Keith>    '(step N) -- do N steps
    Keith>    '(something-else FOO BAR) -- do something else (with parameters)

Thanks for these.  In general, I prefer Keith's notation here.
However, on the idea in general, why do you think that we need to
allow the thunk to return these codes?  If the thunk wants to display
something, why shouldn't it just do it?

In the case of 'break, I think there is a good reason.  It may be that
you simultaneously hit two breakpoints, yet you don't want to go
interactive twice.  Or, if one of the breakpoints just displays
something, and the other goes interactive, you want to see the
displayed information before going interactive.

Are there similar arguments in favour of '(display ...) and '(warn
...)?

Finally, I don't see why the 'step value is useful.  If it's for cases
where the system doesn't allow you to put a breakpoint exactly where
you want it, perhaps we should remedy that more explicitly.

        Neil