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

[Zoltan Somogyi]

On 28-Aug-2002, Mark Brown <dougl at cs.mu.OZ.AU> wrote:
> 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.

I am questioning how useful this distinction is. I am not saying it has no
value; clearly it does. I am merely questioning whether its value outweighs
the added problems posed to the user of having the declarative debugger
confused about what happens inside shallow traced procedures. 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).

(3) would work, but it would also undermine the point of shallow tracing:
the fact that it adds much less overhead than deep tracing. In theory, we
could probably optimize away some hidden events, probably at the cost of
possibly complicating the annotated trace, but I am not sure we could
optimize away enough.

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.

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

That's right. However, "its completion is valid in the intended interpretation"
is not the only assertion a programmer may wish to make. "It will always
compute results that are valid in the intended interpretation" is another.

> Desirable for whom, the users or the implementors of the declarative debugger?
> 
> 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.

When you offer the user a limited set of choices (deep vs shallow, Howard vs
Keating), their choice of one of those alternatives does not imply that they
would not have chosen a third alternative had it been available.

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?

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?

I suppose we could implement *two* new trace levels, interface tracing as
I described and a new version of shallow tracing, say shallow_decl, which
has the modification described in point (3) above. We could then either
remove the old form of shallow tracing, or treat procedures compiled with
the existing form of shallow tracing as in point (2). That would not be ideal,
but it would be necessary to provide the right contexts to the declarative
debugger.

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