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

[Zoltan Somogyi]

On 19-Aug-2002, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> In order for users to fix it, they need to
> (1) understand the meaning of the different annotations
> (2) understand the C code fragement which was broken
> (3) figure out which annotation is appropriate
> (4) modify their source to add the annotation
> 
> Part (4) is fairly easy, but (1)-(3) impose a reasonably significant
> burden on users, IMHO.

(1) has to be done only once.

For 99+% of cases, (3) is trivial once you have done (2).

In the 90+% of cases which are will_not_call_mercury, (2) is trivial too.

> Isn't there some way to enable users who want it to get this benefit without
> imposing the costs on those who aren't using it?
> 
> For example, leave `--trace-table-io-require' as optional,
> and not implied by `--require-tracing'.  Make the mdb "retry"
> command check whether it might be retrying over an I/O action which
> was not appropriately annotated,

I don't know any simple, efficient way to make that check that doesn't involve
transforming unannotated I/O primitives too, in some fashion, to record
when they are executed. I may look into transformations for unannotated
primitives, but in order to distinguish I/O actions by properly annotated
predicates from actions by unannotated predicates, each element in the I/O
table will have to become bigger. (Without --trace-table-io-decl, table
elements do not identify the predicate they came from, for reasons of space.)

The alternative is for the implementation to say that

- when you compile a will_not_call_mercury I/O primitive in a debug grade,
  you are implicitly adding a tabled_for_io annotation for it, and

- when you compile a may_call_mercury I/O primitive in a debug grade,
  you are implicitly adding a not_tabled_for_io annotation for it.

In both cases, the implicit annotation can of course be overridden by an
explicit one.

In 99+% of cases, this will do the right thing, and in the cases where it
doesn't, the symptom will probably be some repeated output when you backtrack
over a may_call_mercury primitive that actually does I/O itself, not via
Mercury code it calls.

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