[m-dev.] Re: proposed command set for the internal trace based debugger

[Peter Schachte]

On 5 Jun 1998, Lee Naish wrote:
> Peter Schachte <pets at students.cs.mu.oz.au> writes:

> >  EXIT	(correct solution)	|	(incorrect solution)
> >		creep		|	     retry, creep
> 
> This is the best you can do for wrong answer diagnosis using the
> standard Prolog commands.  Notice that after retry you need to creep,
> that is, re-execute things.  This brings up the questions about IO etc.

This doesn't worry me very much.  It sounds like Zoltan and Fergus have a
good solution for this (though I'm a bit worried about memory consumption
for industrial-strength debugging).

> ... by doing a retry (jumping back
> to the call port of p) we lose the execution path through the body of the
> clause which lead to the wrong solution and we have to reconstruct it
> with lots of manually intervention (sometimes you want skip, sometimes
> you need creep).

You have to navigate to the error in any case.  The proposed "good" and
"bad" commands were designed to make that simpler for the user.

>  There can be multiple correct answers to q, r and s
> which are irrelevant to the bug because don't lead to the instance of t
> which has the wrong answer.  You still have to look at them all.  With
> my method you look at (at most), one exit port for each of t, s, r and q
> (in that order).

This is a pretty convincing argument.

My concern about this approach is that the code will, I expect, execute at
"leap speed" at best, in order to keep enough information around to trace
backward. This is quite slow.  With my approach, code executes at "skip
speed," which can be pretty close to, if not equal to, full compiled speed. 
If it's a big computation where almost all subcomputations don't contain any
errors, leap speed may be impractical.  Imagine using your approach to debug
the Mercury compiler compiling a big source file, for example.  You'd get
old and die waiting for the computation to finish.  When it did, though,
your grandchildren would very quickly trace back to find the bug. 

Maybe the best approach would be a hybrid.  The computation could procede as
you suggest to a certain depth, and just skip below that.  After the
computation, tracing would procede as you suggest until you reach an
erroneous computation that was skipped over.  Then recursively apply the
hybrid approach.


-Peter Schachte               | May the road rise up to meet you, May the
mailto:pets at cs.mu.OZ.AU       | wind be always at your back, And may God
http://www.cs.mu.oz.au/~pets/ | hold you in the hollow of His hand.
PGP: finger pets at 128.250.37.3 |     -- Old Irish Blessing