[m-dev.] Re: proposed command set for the internal trace based debugger

Peter Schachte pets at students.cs.mu.OZ.AU
Wed Jun 3 15:08:53 AEST 1998


On 3 Jun 1998, Lee Naish wrote:

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

I assume you're keeping a "journal" of the whole execution?  I don't think
that's practical for debugging real applications.  Sure, the traversal would
be lightening fast, but collecting the journal would take forever, and a lot
of space.  And for most debugging sessions, you'll only ever visit a tiny
part of it.

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:  good and bad.  Here's what they do at different
ports (using Prolog debugger terminology):


  port		good		|		bad
  ----	------------------------+------------------------------------
				|
  CALL	(admissible call)	|	(inadmissible call)
		skip		|   retry immediate parent, then creep
				|
  EXIT	(correct solution)	|	(incorrect solution)
		creep		|	     retry, creep
				|
  FAIL	(no missing solutions)	|	(missing solutions)
	creep to next CALL,	|	     retry, creep
	EXIT or FAIL port	|
				|
  REDO	(you should never arrive at this port using these commands,
	 so it doesn't much matter what they do here.  Just do
	 something vaguely sensible, like:)
		creep		|		retry

Of course, you can take this much farther, recording which solutions are good
and bad, which goals are admissible and inadmissible, and which goals should
have more solutions than they do.  But I suspect the cost of recording all
that will be too high for debugging real programs.


-Peter Schachte               | The fantastic advances in the field of
mailto:pets at cs.mu.OZ.AU       | communication constitute a grave danger to
http://www.cs.mu.oz.au/~pets/ | the privacy of the individual.
PGP: finger pets at 128.250.37.3 |     -- Earl Warren 




More information about the developers mailing list