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

[Zoltan Somogyi]

On 30-Aug-2002, Mark Brown <dougl at cs.mu.OZ.AU> wrote:
> No, they mean the interface events of procedures whose nearest traced
> ancestor is deep traced (or greater).  Procedures in shallow traced modules
> which (a) are not exported, and (b) do not have their address taken, should
> never need to generate interface events.

That would be nice if you could do it. But I fear that in the absence of
interface events for *all* procedures, the algorithms we use in the
declarative debugger will fall into performance black holes.

At the moment, we rely reasonably heavily on the sizes of procedure bodies
being naturally limited. We have algorithms (e.g. searching for matching cond
and nege events) that are linear in the number of linked events between a pair
of interface events. As long as all events in such lists come from a single
procedure call, that is fine. If you omit interface events, you get lists
which consist of events from many (possibly hundreds of thousands) calls.
You lose skip links such as the ones that go from each fail/exit node to the
previous exit. The trace may still have enough skip links that the operations
we want to do have bounds similar to the bounds imposed by procedure body size,
but I would need to see details to be convinced.

> If one of the dependant modules is compiled with full tracing,
> then I'm contending that this optimization is not safe, because it ignores
> the assertion by the programmer that the dependant module should not be
> trusted.

You keep missing my point.

You can view the compilation of a module with full tracing (deep, decl,
whatever) as saying "I don't trust this module, period" (1). Or you can view
it as saying "I don't trust this module in general, but I do trust some parts
of it or some patterns of calls to it. Those are the parts used by (or
patterns of calls generated by) the dependent modules B, C and D" (2).

At the moment, there is no way for programmers to separate these two
assertions, so you can't know whether they mean (1) or (2).

> If we were to make this optimization safe for procedural debugging (e.g.
> by doing some sort of analysis) then, yes, I agree it would be good to
> also do this for declarative debugging.  But we currently have no way of
> checking that it is safe.
> 
> > 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 they assert that a dependant module should not be trusted by passing the
> '--trace decl' option to it, and we trust that module by not generating events
> for it, then I'm afraid that it would be us who are wrong rather than them.

That is true only if you have read the programmer's mind and determined they
meant (1) above, not (2).

With my proposed system, programmers *can* separate the two assertions.
If they compile no module with interface tracing, they mean (1). If they
compile some modules with interface tracing, they mean (2), with the interface
traced modules playing the role of B, C and D.

I ask again, why are you saying "no, people couldn't possibly want that,
and if they do want that they are wrong"?

> Precisely.  In particular, compiling module A with deep (or greater) tracing
> is a direct indication that the module shouldn't be trusted.

Maybe, maybe not. See above.

>  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?
> 
> Since when does the level of trust in a module depend on who is calling it?
> Either you trust it, or you don't.

What if the only predicate you call from list.m is append? Are you saying
you can't trust append unless you also trust list__map_filter_foldl_x_y_z?
That's pretty extreme.

In any case, I suspect we will make more progress if we discuss this in person,
say on monday afternoon.

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