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

[Zoltan Somogyi]

On 30-Aug-2002, Mark Brown <dougl at cs.mu.OZ.AU> wrote:
> I am more optimistic than that.  In fact, I can't at the moment foresee
> any problems with the following (I still need to think about it some more,
> though):
> 
> We produce, in addition to the existing events, just the following (hidden)
> events:
> 
> 	- cond, then, else
> 	- nege, negs, negf
> 	- first_disj, later_disj
> 
> The first two groups provide information that we need to interpret the
> annotated trace correctly.  The disj events are not really necessary, but
> can help to prune some questions that are irrelevant because they have been
> backtracked over.

The existing events above mean the interface events.

Deep traced procedures generate, beside the interface events, the following:

 	- then, else
	- switch
 	- first_disj, later_disj

In other words, this new, declarative-debugger-compatible form of shallow
tracing generates roughly as many events as deep tracing does, and (depending
on the number of if-then-elses and negated goals versus the number of switches)
maybe more. This means that it is no longer useful as a way of lowering
overheads.

Consider the library. Since we compile it with --trace minimum, which means
it is compiled with shallow tracing in debug grades, we trust the entire
library. Yet cross-module calls in the library still incur the overhead
not just of a call to MR_trace but also (since MR_trace_enabled is true)
of the check of the MR_trace_from_full. If we add hidden events, it will
incur this overhead on many more events. If we compiled the whole library
with interface tracing, we wouldn't need these extra events, and the overhead
would be significantly smaller (the MR_trace_enabled check would fail, so we
wouldn't even get to the MR_trace_from_full check).

Trusting entire libraries is certainly something that people frequently
wish to do, and being able to use that to reduce debugging time strikes me
as worth while. Why are you saying "no, people couldn't possibly want that,
and if they do want that they are wrong"?

> > 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?
> 
> Yes.  Users can effectively make inconsistent assertions: they may compile
> a module with interface tracing but compile one of its dependencies with
> full tracing.

Whether that is or is not an inconsistency depends on what assertion you see
shallow tracing as making.

If the assertion is "I trust this module", then there is no inconsistency:
the assertions made by both kinds of tracing simply add to the set of trusted
modules. There can be inconsistency only if the assertion is "I trust this
module, but I definitely do not trust the modules it depends on, except the
ones I trusted by compiling them with shallow tracing".

Why do you think it natural for programmers to state "I do not trust module A"
by compiling module B (which calls module A) with shallow tracing? Is the
trace level with which the programmer compiles module A itself not a more
direct indication? And if you accept that programmers should be able to state
"I do not trust module A" with the trace level of module B, why are you
against the programmer being able to say "I trust module A, at least when
called from module B" by specifying interface tracing for module B?

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