proposed command set for the internal trace based debugger
Lee Naish
lee at cs.mu.OZ.AU
Fri Jun 5 12:57:19 AEST 1998
Peter Schachte <pets at students.cs.mu.oz.au> writes:
>On 3 Jun 1998, Lee Naish wrote:
> > It is possible to do declarative debugging of wrong answers without
> > repeating forward execution if you have the right set of commands.
>I assume you're keeping a "journal" of the whole execution?
No. As I said, you just need to reverse the execution back to a certain
event and print it, just like retry. To implement this kind of thing
some information will need to be kept around of course.
>I think a skip/retry debugging scheme makes the most sense. But I think a
>couple of flexible debugging commands can give a crude simulation of
>declarative debugging
> 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.
With my command set you never need to re-execute. Also, consider the
following code:
p( ) :- q( ), r( ), s( ), t( ).
where things are nondeterministic and t (and so p) returns a wrong answer.
Having found the exit port of p with the wrong answer we know we have a
bug within the execution of p. However, 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). 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).
lee
More information about the developers
mailing list