proposed command set for the internal trace based debugger

[Fergus Henderson]

lee at cs.mu.OZ.AU (Lee Naish) writes:

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

Yes, I meant SLD(NF) trees.

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

Ah, I understand you now.

This is a nice model, but still a bit more high level than the
one I was thinking of.

>Perhaps you
>were thinking more in terms of the code for p rather than a (each) call
>to it.

Yes.  My idea is that break points are a low-level imperative
operational notion.  You set a breakpoint at a particular *instruction*,
basically.

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

Hmm, that's just an accident of syntax, I'd say.  If you have

	p(1).
	p(2).

then this is really equivalent to

	p(X) <=>
		(
			X = 1
		;
			X = 2
		).

and you can think of the "exit" and "redo" as corresponding to the full stop.

This is a bit like what happens with C debuggers, where a breakpoint
on the '}' at the end of a function definition will catch
all exits from the function, even those via "return" statements
in the middle of the function.

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

If you're using the "break here" command, then it will just
set a breakpoint at whatever the current port is.

If you're using the "break <predicate-name> [<port>]" command,
then you just specify the port (if you don't specify one,
the default is the CALL port).

--
Fergus Henderson              | Designing grand concepts is fun;
fjh at cs.mu.oz.au               | finding nitty little bugs is just work.
http://www.cs.mu.oz.au/~fjh   | -- Brooks, in "The Mythical Man-Month".
PGP key fingerprint: 00 D7 A2 27 65 09 B6 AC  8B 3E 0F 01 E7 5D C4 3F