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

Zoltan Somogyi zs at cs.mu.OZ.AU
Tue Aug 20 13:09:59 AEST 2002

On 19-Aug-2002, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> Perhaps even just setting a single global boolean flag would be enough?

No, it wouldn't. You need to know not just whether you had a call to an
unannotated I/O primitive. If you want to avoid spurious warnings to the user,
you also need to know whether there was such a call in the range of I/O
actions a given retry action is backtracking over.

> > 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.
> I think that approach would probably be less painful for most users.

OK, I will do that.

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

I'll think about whether there is any way to avoid the problem without
imposing overhead on code that doesn't need it.

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