proposed command set for the internal trace based debugger

[Lee Naish]

Peter Schachte <pets at students.cs.mu.oz.au> writes:

>On Wed, 3 Jun 1998, Fergus Henderson wrote:

>[Re: the distinction between spy and break points]

>But I'm not so sure that break points correspond very closely to break
>points in imperative language debuggers.

I agree.  You could argue the convention break points stop the execution
when the flow of control reaches a certain point.  You can argue a
similar thing for spy points.  A major difference is that control can
reach a certain point in a greater variety of ways: call+fail and
exit+redo are the same program points but how we get there is different.
Of course spypoints actually specify two program points (those above),
but even if only one was specified, it would correspond to two ports.

Getting back to my previous suggestion, and related to REDO ports and
what to do with IO etc:

It is possible to do declarative debugging of wrong answers without
repeating forward execution if you have the right set of commands.
Basically you do a single reverse scan of the trace, requiring backwards
execution followed by printing the appropriate trace line.  Its best to
think of it as a depth first right to left search of the proof tree.
Nodes in the proof tree correspond to exit ports.

You need two operations:

1) From the parent node, get to the rightmost child: this is just
"skip/step -1" getting from one exit port to the previous one in the
trace. (if the previous line is not an exit then we are at a leaf)

2) From a child, get to the previous child: this is more tricky, but if
we assume there are redo ports then we scan backwards looking for an
exit (at the same call depth as the current one) which is not matched by
a subsequent redo (like treating exit as "(", redo as ")" and searching
backwards for an unmatched "(" ). (if we get to a port with a smaller
call depth then there is no previous sibling)

For nondeterministic code this allows you to use a much more efficient
debugging strategy than would otherwise be the case.  For deterministic
code the debugging strategy doesn't make so much difference but it might
be useful for avoiding some of the problems with recomputation.

	lee