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

Zoltan Somogyi zs at cs.mu.OZ.AU
Sun Aug 18 17:27:09 AEST 2002

Now that I/O tabling and declarative debugging are both reasonably mature,
it is time to make their benefits widely available by documenting them
and making them easier to use.

I propose two changes:

- Make --trace-table-io-require synonymous with --require-tracing. This would
  make the procedural part of I/O tabling part of every .debug grade. The space
  and time costs of this are small; I just measured them as 0.6% and 0.8%
  respectively. The main implication is that you would get a compile-time
  error if you tried to compile a module containing a I/O primitive that
  doesn't have any kind of tabled_for_io annotation in a .debug grade.

- Add a new grade component, called something like .decl or .decldebug,
  controlled by an option such as --require-decl-tracing. Just as
  --require-tracing disallows trace level none, --require-decl-tracing
  would disallow trace levels none, shallow and deep, leaving a choice
  only between trace levels decl and rep. (Eventually, we could add a version
  of shallow tracing that is suitable for declarative debugging, either by
  marking the boundaries of negated contexts or by suppressing all events
  inside shallow traced procedures.) These grades would guarantee that you
  could apply declarative debugging to their executables. To ensure this,
  --require-decl-trace would also imply both --trace-table-io-require and
  --trace-table-io-decl, thus insisting that all I/O primitives be tabled
  in a manner suitable for declarative debugging.

  Executables in these grades would be very large, significantly larger than in
  plain .debug grades, but this is already true for programs compiled with
  trace levels that enable declarative debugging.

These changes would obviously require a lot more documentation in the user
guide and the language manual about the new grades, options, and the (so far
not really documented) tabled_for_io annotations, but I don't want to start
work on that documentation without a prior discussion and rough agreement
about the broad shape of the system I am documenting.

Comments? Proposes for better names?

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