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

[Fergus Henderson]

On 29-Aug-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> Even after
> we introduce .decldebug grades, we don't want to outlaw cheap forms of
> tracing, so we have the following choices:
> 
> 1. Keep shallow tracing as it is now, and let the declarative debugger be
>    confused sometimes. I am strongly against this option.
> 
> 2. Keep shallow tracing as it is now, but ignore all events inside shallow
>    traced calls when building the annotated trace.
> 
> 3. Redefine shallow tracing to add extra events that let the declarative
>    debugger make sense of what is happening inside shallow traced procedures.
>    This would mean generating interface and context events for every procedure
>    in a shallow traced module, with all those events being hidden from the user
>    except for the interface events of the exported procedures (and those whose
>    addresses are taken, as now).

What about

	4.  Keep shallow tracing as it is now, but make the declarative
	debugger smarter, so that it doesn't get confused by shallow
	traced procedures.

?

> Interface tracing blends approaches (2) and (3). It has low overhead, its
> use never confuses the declarative debugger, and in many cases it is definitely
> what the programmer wants, because the programmer often does want to assert
> that they trust not only the given module but also all the modules it is built
> upon. I know I do.

If you trust the other modules that it is built on, then presumably you
would have compiled them with shallow tracing too, in which case the
problematic situation won't arise.  The problematic situation arises only
in the case where something that you've compiled with shallow tracing
calls something that you've compiled with deep tracing.  If you've
compiled something with deep tracing, then presumably you don't trust it
(otherwise why use deep tracing?), and hence you can't trust its callers
either (since their correctness depends on its correctness).

> If we offer both shallow tracing and interface tracing, users can choose
> interface tracing if they trust that module and all the modules that it
> depends on, or they can choose shallow tracing if they trust that module only.
> Do you have a problem with this?

I would question the usefulness of interface tracing.

Providing users with more choices is not an advantage if the alternatives
aren't useful.

> The existing implementation of shallow tracing confuses the declarative
> debugger, so I am proposing that shallow tracing not be allowed in .decldebug
> grades. Do you have a problem with this?

That would be OK for the short term, but in the medium to long term,
I think it would be better to modify the declarative debugger so that
it doesn't get confused in such situations.

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