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

[Mark Brown]

On 29-Aug-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 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.

Agreed.

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

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.

Note, however, that Fergus' suggestion is worth pursuing.  I need to think
about that some more, too.

> 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.  If we allow an inconsistency like this at all, we should be
conservative and assume the worst: the module with full tracing can't be
trusted.  But this plan would assume the opposite.

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

No, since that is similar to what we currently do.  Declarative debugging of
shallow traced code is not allowed (admittedly the debugger can't catch all
attempts at it, though).

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