[m-rev.] for review: fix two bugs in the management of I/O tabling

[Ian MacLarty]

On Wed, Sep 26, 2007 at 01:43:59PM +1000, Zoltan Somogyi wrote:
> On 24-Sep-2007, Ian MacLarty <maclarty at csse.unimelb.edu.au> wrote:
> > I think your diagnosis and fix of the second bug is wrong.  See below.
> 
> I agree; I was misremembering a problem I had before my break. The actual
> problem is indeed different. This updated diff locates and marks the problem,
> but I think you (Ian) and I should discuss the proper solution before any more
> work is done.
> 
> I implemented your other suggestion. The updated log and diff follow.
> (So much has changed that an interdiff would not be very useful.)
> 
> Zoltan.
> 
> -----------------------------------------------------------------------------
> 
> Fix a bug in the handling of I/O actions by the debugger: the procedural
> debugger didn't implement the documented commands for printing I/O actions.
> Also implement some new variants of the print commands to make it easier
> to print I/O actions.
> 
> Also track down and pinpoint a bug that caused the declarative debugger
> to ask questions from *outside* the tree it was asked to debug, as shown
> by this example from a new test case compiled in a decldebug grade (so that
> the library, and thus io.read, gets compiled with deep, not shallow tracing):
> 
> -----------------------------------------------------------------------------
> 
> mdb ./io_read_bug
>        1:      1  1 CALL pred io_read_bug.main/2-0 (cc_multi) io_read_bug.m:22
> I/O tabling started.
> mdb> g 4
> Please input the number of queens and a period:
>        4:      3  2 CALL pred io.read/3-0 (det) io.m:4240 (io_read_bug.m:24)
> mdb> f
> 5.
>      513:      3  2 EXIT pred io.read/3-0 (det) io.m:4240 (io_read_bug.m:24)
> mdb> dd
> [1, 3, 5, 2, 4]
> main(_, _)
> 31 tabled IO actions: too many to show
> Valid?
> 

I think the problem here is that the standard library is trusted by
default, so the declarative debugger will never ask any questions about
io.read (you can untrust the standard library with "untrust 0" IIRC).

Because the io.read node is trusted (as are all its descendants), the
declarative debugger is continuing its search up the call tree, arriving at the
call to main.

The behaviour of continuing the search up the call tree is particularly
useful when working back from a call to throw, but in this case it's
unintuitive.

Perhaps the fix is to never trust the initial node, and always require
an answer from the user for the initial node?  Although, if the initial
node is throw, then it's probably desirable for the declarative debugger
to jump up the call tree to the first untrusted ancestor.  Not sure.
Are there any other opinions?

Perhaps the solution is to document this behaviour more clearly.

Ian.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------