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

[Fergus Henderson]

On 27-Aug-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 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"

I agree with Mark, this is not a good rationale for a new trace level.
This problem would be better solved by piping the output of the relevant
tests through "sed -e 's/[0-9]*/<number>/g'", I think.

If there is really a need for a new tracing level, it should be justified
on its own merits.

> I therefore propose a new trace level, tentatively called "interface"
...
> 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.

If they don't, then that is clearly an omission in our test suite,
since this is an important case to test.

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

Uh, could you remind me again why the declarative debugger needs to know
whether such calls are in negative contexts or not?

As a human debugger, I am quite capable of inferring whether or not
a shallow-traced procedure is buggy (*) without needing to know whether
the deep-traced procedures that it calls were called from a negative
context or not.  If the auotmated debugger can't make such inferences,
then perhaps the right solution is to teach it to do so.


(*) Actually, this is not quite correct.  You can only infer whether
there is a bug in the shallow-traced procedure or in any of the other
shallow-traced or untraced procedures that it calls, not whether there
is a bug in the shallow-traced procedure itself.  (**)

(**) Actually, even this is not quite correct.  If there is a bug, it
might be in the Mercury implementation, or in the C compiler, or in the
OS, or the hardware...


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

Note that procedures whose type includes a class constraint also need
the same treatment as higher order procedures.

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

I don't thing that would be a good idea, because shallow tracing is more
useful, IMHO; you can build the top-level module with shallow tracing, for
example, and still debug deep-traced modules that it calls, whereas that
wouldn't work for interface tracing.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------