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

[Zoltan Somogyi]

On 18-Aug-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> - Add a new grade component, called something like .decl or .decldebug,
>   controlled by an option such as --require-decl-tracing. Just as
>   --require-tracing disallows trace level none, --require-decl-tracing
>   would disallow trace levels none, shallow and deep, leaving a choice
>   only between trace levels decl and rep. (Eventually, we could add a version
>   of shallow tracing that is suitable for declarative debugging, either by
>   marking the boundaries of negated contexts or by suppressing all events
>   inside shallow traced procedures.)

I discovered that in practice, we *need* a version of shallow tracing for
declarative debugging. If we don't, then in .decldebug grades, the event
numbers in the outputs of the debugger test cases depend on the exact
implementation details of the library functions called by those test cases,
and this is too much of a nuisance for maintenance.

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.

This solves two problems. The first is the maintenance problem with the
expected outputs, since I don't think any debugger test cases call higher
order library functions. The second is the fact that declarative debugging
doesn't work with trace level shallow. The problem is that a shallow traced
procedure can call a decl traced procedure in another module, and if it does
so, the declarative debugger doesn't know whether the decl traced procedure
is a negative context or not. This will never happen with interface tracing,
because you won't ever get an event from inside an interface traced procedure
(one in category 2). This is normally what you want if you trust the interface
traced procedure, but for higher order procedures, in general you cannot extend
blanket trust to their higher order arguments. This is the reason for treating
category 1 procedures with a higher effective trace level.

This trace level is in many ways simpler than trace level shallow, so once
it is implemented, we may wish to emphasize it instead of shallow tracing.

Comments?

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