|
(0000764)
|
|
zs
|
|
2014-08-25 02:45
|
|
I/O tabling has two main purposes. The first and more important is to allow the debugger to replay parts of the program execution for the programmer, which requires making I/O operations idempotent (so that we get the same results on the second, third etc "execution" as on the first). The second purpose is to let the person using the debugger actually see a list of the I/O actions, and their results.
I believe that the root of the problem here is that the compiler can do the second part only if it has access to the type_infos describing the types of the arguments of the I/O action. With the current infrastructure for representing typeclass information, this is not always possible in the presence of typeclass constraints on I/O action predicates. The reason is that polymorphism.m can hide the typeinfo for a type variable that is subject to a typeclass constraint arbitrarily deep inside the typeclass_info for that constraint, but the RTTI can encode such locations only up to a fixed depth (currently only the shallowest embedded is encodable). Rather than allow I/O tabling for SOME typeclass-constrained predicates but not others, the current system consistently does not allow it for any. Of course, the error indication could be better.
When I designed the I/O tabling system, I did NOT design it for I/O actions whose types include typeclass constraints. There were two reasons for this. First, none of the I/O actions in the Mercury standard library have typeclass constraints; second, I/O actions are written in languages like C, which themselves have no class system.
While fully fixing this limitation would be desirable, it would also be a huge amount of work. However, there are two possible short term fixes.
The first fix is actually a simple workaround. I haven't tested it with mercury_cairo, but it works with bug354.m: simply compile the module with the mmc flag --trace-table-io-only-retry. This tells the compiler to generate I/O tabling code that serves only the first purpose I mentioned above (making I/O actions idempotent in mdb), but not the second (printing those actions in mdb).
chemoelectric, please enable this flag for all the modules of mercury_cairo, and tell us what happens.
The second possible fix, which I will look into in the next few days, would make this unnecessary by automatically imposing the effect of --trace-table-io-only-retry on any I/O predicates that have typeclass constraints on them. |
|
bug354.m (2,632) 2014-08-24 23:14