[Mono-dev] Messing with the debugger, bidirectionality

[Jonathan Morgan]

On 11/20/06, pablosantosluac <pablosantosluac at terra.es> wrote:
> Well, AFAIK the debugger will be a priority, and a huge step ahead... Ok,
> don't want to bother with confusing topics but I just heard about the
> following guys doing a bi-directional debugger:
> http://undo-software.com/undodb_rationale.html
>
> Do you imagine something like that on Mono??? :-)

As is said on the site you cite, this has the potential to greatly
enhance the development process.  However, such things are not new,
though they are uncommon.  For example, Turbo Debugger supported it
many, many years ago (15 years?), as can be seen in early release
notes (http://bdn.borland.com/article/16305).  Prolog debuggers have
also supported retries for a long time.

However, it is important to be aware that there are various technical
problems with such debuggers, the main ones being that it takes a
large amount of memory to store all the changes to the program state,
and, even if you do do this, there are still many things that are
outside of the control of the system (e.g. open files to be read from,
bytes coming over the network, etc.)  Very nasty things can happen if
you re-run your program and it closes a file that has already been
closed, and the bug may be impossible to re-produce if it relied on a
particular sequence of bytes that came over the network.  I cannot
think of a particularly good way to handle these problems in any Mono
debugger, as it is difficult to know which functions can be safely
re-run and which functions can't.

In a truly declarative language it is possible to safely re-try
without requiring large amounts of memory to store all past results.
For example, Mercury's debugger only needs to store the results of any
calls that have made I/O, which is known as part of the language.
These results can then be reused without having to re-perform the I/O
action, not leading to any of the problems stated above.  A paper on
the problem and Mercury's solution can be found at
http://www.cs.mu.oz.au/research/mercury/information/papers.html#aadebug03-paper.

While not trying to discourage you if anyone does wish to try such a
project, be aware that there are various technical problems with
reversing the flow of time in imperative languages.

Jon