[m-dev.] grades & options for tracing and debugging

[Peter Schachte]

On Fri, 13 Mar 1998, Fergus Henderson wrote:

> The code generated for say foo/1 with `--trace-all' should look like this:
> 
> 	foo_1_0:
> 		MR_tracing = TRUE;
> 		if (MR_trace_enabled) {
> 			MR_trace(MR_PORT_CALL, ...)
> 		}
> 		...
> 		if (MR_trace_enabled) {
> 			MR_trace(some intermediate port, ...)
> 		}
> 		...
> 		if (MR_trace_enabled) {
> 			MR_trace(MR_PORT_EXIT, ...)
> 		}
> 		proceed();

One question not quite answered by this:  how do you treat tail recursive
predicates?  In the redesign of the Quintus debugger we quite deliberately
decided to make the debugger reflect the actual execution of the program,
rather than the naive view of the execution.  So a recursive call will have
a call port but no corresponding exit port:  a call to append([1,2,3],X,Y)
will have a call port for each tail of the list [1,2,3], but only an exit
for the first call.  This reflects the execution.  Of course, append isn't
tail recursive under Mercury, but you get the idea.  I never heard of a
complaint from anyone who wanted to see all those exit ports.  Also, the
Quintus debugger reflects indexing by only showing clauses actually tried. 
This would work even better under Mercury. 

So do you plan to turn off obvious optimizations like indexing and tail
recursion optimization when debugging to give a simple model, or do you plan
to make the debuging session reflect the actual behavior of the (optimized)
program?


-Peter Schachte			| He who asks is a fool for five minutes, but
pets at cs.mu.OZ.AU		| he who does not ask remains a fool forever.
http://www.cs.mu.oz.au/~pets/	| -- Old Chinese saying 
PGP key available on request	|