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

[Fergus Henderson]

On 16-Mar-1998, Peter Schachte <pets at students.cs.mu.oz.au> wrote:
> 
> One question not quite answered by this:  how do you treat tail recursive
> predicates?

Currently if you enable tracing, this will prevent tail recursion
optimization.

Note that the compiler doesn't explicitly disable tail recursion
optimization for this case, it is just that the extra calls to MR_trace()
will mean that the optimization which detects tail calls will never
find any.

The compiler *does* explicitly disable other optimizations that might
affect the trace.

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

The tradeoffs are different in the case of Mercury.
Quintus doesn't do that much in the way of optimization.
Mercury does a whole heap of high-level optimization (inlining,
specialization, etc.) with more on the way (e.g. deforestation).

It would be reasonable to have an option for debugging optimized
code, but I don't think it should be the default.

Note that this option would be quite difficult to implement perfectly;
for example, if you don't want tracing to disable tail call
optimization, then you need to detect tail calls at the time
tracing code is added (code generation time), whereas currently
they are only detected later on (during LLDS->LLDS optimization).
Thus for the moment I think we should probably just put this on the
"wish list" (also known as the "too hard" basket ;-) and then
forget about it.

> So a recursive call will have
> a call port but no corresponding exit port:

If we were going to do it that way, then I think it would
be better to add a new "tailcall" port.

> Also, the
> Quintus debugger reflects indexing by only showing clauses actually tried. 
> This would work even better under Mercury. 

The current debugger does reflect indexing.  Our "4-port" debugger
actually has extra ports for if-then-elses and switches.

Note that since indexing affects determinism analysis,
it should (IMHO) be considered part of the standard operational
semantics, rather than an optimization.
So this is not an inconsistency in our design.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.