Anyone relying on "break-at" breakpoints?

[Neil Jerram]

This email pertains to the debugging and breakpoint infrastructure in
Guile CVS, which has so far only been released as part of my
guile-debugging package.  If you've never looked at or used this
infrastructure, you can safely skip the rest of this message.

I've been wrestling for a while with specifying and documenting
exactly how "break-at" breakpoints should behave, and have concluded
that the problem arises from how these breakpoints are defined.
Therefore I'm looking at removing them (in their current form), and
hence this email to check if anyone would be inconvenienced by that.

A break-at breakpoint is defined by a file name, a line number and a
column number, and it means that Guile should break when executing the
code from the named file whose opening parenthesis is at the specified
line and column.  It should work both if the relevant code was loaded
before the breakpoint was defined, and if the code is loaded after the
breakpoint is defined.  In other words, it's the Guile equivalent of
GDB's "break <filename>:<line>" for C.

The trouble is that Guile (unlike C) is an interactive environment.
Someone might write a first version of a function:

(define (my-func . args)
  (let ((a (car args))
        ...)
    ...))

then evaluate and try it, then decide that it works better with an
internal definition:

(define (my-func . args)
  (define (helper arg1)
    ...)
  (let ((a (car args))
        ...)
    ...))

then evaluate the new version, and so on.  Suppose that when trying
out the first version, the coder defined a break-at breakpoint at the
position of the "(let".  Then after the redefinition (and assuming the
current specification and implementation of break-at breakpoints), the
breakpoint would be in the wrong place: it would apply to the
"(define", and would not apply to the "(let" in its new position.

This is a simple example, but there are many possible variations and
complications of it (for example, lambda-constructing code, which has
the consequence that we cannot say that there is only one "correct"
version of the source code at a given time), which make finding a nice
general solution very difficult.

By way of contrast, the other kind of breakpoint ("break-in") does not
suffer from this problem, because it is defined in a way that relates
more persistently to the code (even as the code changes).  A break-in
breakpoint is defined as

  break-in <procedure-name> [<module-or-file-name>]

and means break at the start of that procedure.

It could be argued that break-at breakpoints are fine for the "static"
case - i.e. for debugging a program and not changing it at the same
time - and hence we should keep them for this.  But I'd much rather
develop a better conceptual solution that works equally well for both
the static and interactive cases.

Therefore, I'm planning to simply drop "break-at" breakpoints (and the
associated <location-trap> trap), and then to reconsider the scenarios
for which I thought "break-at" was the solution, to work out better
solutions instead.

If there are scenarios that you (anyone!) are actually using and
relying on, please let me know, so that I can make sure that I have an
alternative solution ready for you.  If you have any questions,
suggestions or concerns about all this, please let me know those too.

Thanks for reading; I hope it all made some kind of sense. :-)

Regards,
        Neil