[m-dev.] debugging grades and I/O tabling

[Mark Brown]

On 27-Aug-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> I therefore propose a new trace level, tentatively called "interface"
> (naming suggestions welcome). This level divides the procedures in the module
> being compiled into three categories:
> 
> (1) Procedures with one or more higher order arguments that are either in the
> interface or are reachable from the interface via a chain of ancestors that all
> belong to this category.
> 
> (2) Procedures without higher order arguments, either in the interface or
> reachable from the interface via a chain of ancestors that all belong to
> category 1.
> 
> (3) All other procedures in the module.
> 
> This trace level for the module would treat procedures in category 1 as
> if the trace level were "decl" (or possibly as "rep"). It would handle
> procedures in category 2 by generating just the interface events for them.
> After the call event and any redo events, the compiler would save the value
> in MR_trace_enabled and then turn it off; before the exit and possibly fail
> events, it would restore the saved value of MR_trace_enabled. This guarantees
> that we don't get any events from inside the procedure body.  Procedures in
> category 3 wouldn't be transformed at all, since they cannot be reached
> with debugging still enabled.

So if a procedure in category 2 calls another module which is deep traced,
then events from the latter module will be suppressed?  If that module
actually does contain a bug, then the declarative debugger may wrongly
accuse the shallow traced module of being buggy.  I suppose we could fix
this by modifying the declarative debugger to detect when the bug is actually
at the interface of a shallow traced procedure, and if so report that the bug
may be in that procedure or one called from it.  But I'd rather avoid 
weakening the definition of bug in this way, particularly since we go to
all the trouble of avoiding this sort of weakening in the case of higher
order arguments.

Is it possible to extend the analysis to figure out which procedures have
some descendant which is deep traced?  If so, it would be better to do
that than to suppress events from modules that are compiled with trace level
deep.

On the other hand, maybe we can dispense with the requirement that adjacent
events have to be at the same depth or adjacent depths.  For example, we
could generate events only for procedures which contain a negation or
if-then-else, which will cover all possible negated contexts and is a
much simpler analysis.  Since the user probably wouldn't want to see these
events, we could use hidden events like I described in my earlier post.
Offhand, I think the declarative debugger should be able to cope with this,
possibly with some minor tweaks.

Cheers,
Mark.

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------