Re: what happened with gds breakpoints?

[Neil Jerram]

2009/1/12 Andy Wingo <address@hidden>:
> Hi Neil,

Hi Andy,

> Why did you remove GDS breakpoints? The idea sounded nice:

I think because the implementation as was was confusing too many things:

- the idea of being able to specify (in Scheme terms) where a
breakpoint ought to be, equally before or after the relevant code has
been loaded

- extending that so that the specification can be done from Emacs, and
that Emacs, acting as a kind of IDE, has its own persistent idea of
where breakpoints ought to be (which is important in practice because
of programs being likely to be killed and restarted)

- integrating that with everything else that can happen in Emacs,
notably editing code, and trying to make it still work when the
relevant buffers/files are edited, keeping track of when different
bits of a given file are evaluated, etc. etc.

These concepts are still interesting and potentially very useful, but
the mixture as it was was driving me a bit mad, and I thought it best
to just chuck that level away and go back to just traps, and then
gradually work up again from there, trying to be really clear about
usefulness and semantics.

Most of that is still in the future, but one thing that I did add
since that point was the `C-u' prefix for the gds-eval-* commands,
meaning to single step through the relevant code.

>    While they are an important piece of infrastructure, and directly
>    usable in some scenarios, traps are still too low level to meet some
>    of the requirements of interactive development.
>
>    A common scenario is that a newly written procedure is not working
>    properly, and so you'd like to be able to step or trace through its
>    code to find out why.  Ideally this should be possible from the IDE
>    and without having to modify the source code.  There are two problems
>    with using traps directly in this scenario.
>
>    @enumerate
>    @item
>    They are too detailed: constructing and installing a trap requires you
>    to say what kind of trap you want and to specify fairly low level
>    options for it, whereas what you really want is just to say ``break
>    here using the most efficient means possible.''
>
>    @item
>    The most efficient kinds of trap --- that is, @code{<procedure-trap>}
>    and @code{<source-trap>} --- can only be specified and installed
>    @emph{after} the code that they refer to has been loaded.

All of that still stands, I think; but the solution needs more thought
and factorization than it had in my previous experiment.

Regards,
        Neil