proposed command set for the internal trace based debugger

[Lee Naish]

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

>On 03-Jun-1998, Lee Naish <lee at cs.mu.OZ.AU> wrote:
> > Peter Schachte <pets at students.cs.mu.oz.au> writes:

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

>Why?

Because I'm very picky about the word "very":-)
More seriously, its about the difference in flow of control.

>  Spy points are a high level notion closely related to the
>proof tree.

They are not that related to proof trees (which contain *no* information
about failed parts of the search space).  They are closer to SLD trees
(but contain a bit more explicit information).

>At least that's how I see it.

> > 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.

>I don't see why you say that "call+fail" are the same program point.
>Perhaps you meant "call+redo" and "exit+fail"?

No.  call and fail both correspond to the point "just before" a call to
a procedure and exit and redo correspond to the point "just after" a
call:

	..., <call_or_fail> p( ) <exit_or_redo>, ...

For forward execution <call_or_fail> is a call port but for backtracking
(the other direction control can flow in) its a fail port.  Perhaps you
were thinlking more in terms of the code for p rather than a (each) call
to it.  I think its easier to think in terms of calls (as above),
otherwise exits and redos correspond to multiple places in the program
text (the ends of multiple clauses) and call and fail correspond to
different places (before the first clause and after the last,
respectively - the way you have to think about call ports I find less
natrural in this model also).

The "call" view adds extra ammunition for Fergus in a sense, since it
means that adding a spy point means breaking at 2*N program points,
where N is the number of calls to the procedure (though with a very
simple program transformation we can reduce this to 2 points).

Something I'm not quite clear about: if a break point corresponds to a
single port, how does the user distinguish (eg) call and fail?  
Or can't you put break points on backward execution?

	lee

P.S.  I meant to say in my previous posting that I agree with Mireille
that the details of the more complicated tracing commands are not so
important, but we want a basic set of primitives and preferably some
programmable way of combining them into more complicated commands as in
Opium.