[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?
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
--------------------------------------------------------------------------
More information about the developers
mailing list