proposed command set for the internal trace based debugger

[Lee Naish]

Fergus Henderson <fjh at cs.mu.OZ.AU> writes:


>On 12-Jun-1998, Peter Schachte <pets at students.cs.mu.oz.au> wrote:
> > > initial_exit_at_next_level
> > > First exit *on current successful execution path* at next level.
> > 
> > Is this meant to be used at a call port?  Isn't it just creep, then skip?

>I think the idea is that it is meant to be used at an exit port.

Yes, all these commands are for use at exit ports - nodes in the proof
tree correspond exactly to the exit ports on a successful execution path.

>It's a bit like retry, then creep, then skip, except that
>the retry doesn't go back to the call port, it goes to the most recently
>entered redo port for this call.

Thats a closer approximation than Peter's suggestion, but still not
perfect.  Let me explain with some code:

p(...) :- q(...), r(...), s(...).

Suppose we are at an exit for p.  We want to find the exit for q which
leads to this exit for p (there could be several exits for q which lead
to other exits for p or which lead to failure within r or s).  What we
need to do is remember the current exit of p (call it P), turn on
tracing of top level calls to q, r and s, but not stop at any ports of
these calls, only stop at exits of p.  Now, retry p.  After goodness
knows how many ports of q, r and s have been displayed, we get to an exit
of p.  If this is not P, we force failure and repeat.  When we finally
get to P, we are back on the execution path we want.  We search backwards
for the most recent exit of q.  If you understand this, you should also
understand why I suggested traversing the tree backwards - its simpler.

> > > subsequent_exit_at_this_level
> > > Assuming we are currently at an exit on the right path, this will just
> > > take ust to the next exit at this level.
> > 
> > Isn't this just creep, then skip?

Almost.  Assume you are at an exit of q on the right execution path.
Creep gets you to the call port of r and skip will get you to an exit
port.  However, it might not be the right exit port (this exit might
lead to the wrong exit of p or just a failure of s).  Again, we really
need to look ahead in the computation and essentially search backwards.

> > One thing I notice in your overall command set is that it seems to
> > concentrate on erroneous solutions.  How do you find an inadmissible
> > goal if you're always looking at exit ports?

I deliberately concentrated on wrong answers (missing answers are
significantly harder).  There are many possible definitions of
inadmissibility, and different definitions may lead to different
debugging strategies.  However, there is a broad class of definitions of
inadmissibility which allow us to adapt the simple wrong answer
diagnosis algorithms in a straightforward way.  Suppose the definition
is such that if a call is considered inadmissible then all corresponding
exits are also inadmissible - we search the tree in the standard way and
stop when we find a correct node with no erroneous children (the exact
diagnosis will depend on whether there is an inadmissible child or not).

Examples of such inadmissibility definitions are: 1) the call/exit is
ill-typed and 2) the input arguments of the call/exit are ill-typed
(this can be generalised to polymorphic modes and I believe its the best
one to use).

A "non-example" is 3) the call is not instantiated enough (this should
not be a problem for Mercury).

Only considering inadmissibility at exit ports may seem a bit strange.
However, if you think about the typical top-down search strategy, you
only follow sequences of erroneous (sub)computations and an inadmissible
call/exit is only of interest at the very end of the search.  You never
say, for example, this sub-computation is inadmissible so lets examine
its details.

With a (partially) bottom up search it is more of an issue.  If you have
a computation which is inadmissible you want to know if the parent is
inadmissible and looking at the call port is preferable to the exit port
because it typically contains enough information that you want to see and
less information that you don't want to see.

	lee