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

Mark Brown dougl at cs.mu.OZ.AU
Wed Aug 28 18:25:19 AEST 2002


On 28-Aug-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 28-Aug-2002, Mark Brown <dougl at cs.mu.OZ.AU> wrote:
> > So if a procedure in category 2 calls another module which is deep traced,
> > then events from the latter module will be suppressed?  If that module
> > actually does contain a bug, then the declarative debugger may wrongly
> > accuse the shallow traced module of being buggy.
> 
> In a sense, it is. By compiling that module with shallow tracing, the
> programmer implied that he/she believed the code in that module to be correct,
> thus implicitly believing that all the code that it depends on, including such
> code in other modules, to be correct also.

I disagree.  I see this implication as conflating two ideas that are both
referred to as "correctness": correctness in the sense of never producing
any bug symptoms, and correctness in the sense of not containing any bugs.
In my opinion, '--trace shallow' should be an assertion of correctness
in the latter sense, but to allow an implication like the one above means
that the option is treated as an assertion of correctness in the former
sense.

To be clear, let's refer to the latter sense of correctness (incorrectness)
as "bug-free" ("buggy").

> 
> > I suppose we could fix
> > this by modifying the declarative debugger to detect when the bug is actually
> > at the interface of a shallow traced procedure, and if so report that the bug
> > may be in that procedure or one called from it.
> 
> Exactly.
> 
> > But I'd rather avoid 
> > weakening the definition of bug in this way, particularly since we go to
> > all the trouble of avoiding this sort of weakening in the case of higher
> > order arguments.
> 
> I don't see that as a weakening.

It is a weakening in the sense that one definition of buggy node entails the
other, but not vice-versa.  If it is true that "there exists a bug in
procedure P" then it is also true that "there exists a bug in procedure P
or in something called from procedure P", so the latter statement is weaker
than the former.  It doesn't give you as much information about the
location of the bug.

> When you assert that list__filter is correct, you are not asserting that
> every closure passed to it as an argument is correct, since you have no
> control over the actual arguments in calls to list__filter. However, you
> do have control over the implementation of list__filter itself, and by
> asserting list__filter to be correct, you are implying that all the code
> in its implementation is correct.

It is much simpler than that.  A predicate or function (or module, for
that matter) is bug-free iff its completion is valid in the intended
interpretation.  Your first sentence is consistent with this, but not your
second.

> > On the other hand, maybe we can dispense with the requirement that adjacent
> > events have to be at the same depth or adjacent depths.
> 
> I actually think that requirement is a desirable one, 

Desirable for whom, the users or the implementors of the declarative debugger?

If you mean the implementors then I don't agree at this stage, because I
don't see how it makes any major difference to the declarative debugger's
implementation (assuming that required information about negated contexts
is available).

If you mean the users then I definitely don't agree.  Users are allowed to
compile a module with full tracing even if it is called from a module which
is shallow traced.  In order to meet the requirement we need to produce some
internal events from the shallow module and/or suppress some events from the
full traced module, and in each case this goes against the explicit wishes
of the user.

Cheers,
Mark.

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



More information about the developers mailing list