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

[Fergus Henderson]

On 19-Aug-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> > 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 think it would be OK to do that in debug grades.

Perhaps even just setting a single global boolean flag would be enough?
Or, rather than a boolean, perhaps a string (the procedure name)
or a proc_layout.  The debugger would then be able to tell you
the name of *one* of the procedures causing the problem.

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

I think that approach would probably be less painful for most users.

It's not the only alternative.  Another alternative would be for the
implementation to properly handle I/O tabling for foreign procedures which
both do I/O and call Mercury.  This would be a lot more work, of course,
so I'm not suggesting it be done right away.

But it seems like a bad idea to impose a backwards-compatibility headache
on users, when a better implementation of I/O tabling could avoid any
need for such a backwards-compatibility problem.  We might be penalizing
users just to work around what turns out to be a temporary state of affairs.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------