[m-rev.] diff: reset contains_trace_goal if necessary

Peter Schachte schachte at csse.unimelb.edu.au
Fri Nov 10 18:07:09 AEDT 2006


On Fri, Nov 10, 2006 at 05:02:23PM +1100, Mark Brown wrote:
> > and you need to reorder q and r.  If you consider the trace goals to
> > be impure without affecting the purity of p, then you can't reorder q
> > and r, and compilation fails.
> 
> You could do this with two auxiliary predicates: q_traced and r_traced.
> Or if the "trace impurity" doesn't propagate outside of promise_pure scopes,
> then you could wrap each part in its own promise.

You could if you thought of it.  A quick read of the manual section
makes it seem like you can just throw trace goals in your code and
away you go.  The doc should explain the non-contageous impurity of
trace goals, ie, that putting trace goals in a clause really makes
that clause impure (because conjunction is not commutative), without
making the defined predicate impure.  It should make clear that you
can't just stick trace goals in a clause without changing the meaning
of the clause (aside from the tracing), because they force the goals
to be executed in the order written.  Ie, they make a declarative
clause procedural.  It would be helpful to point out that the fix is
to wrap the trace goals together with the pure goals they refer to in
a promise_pure scope (seems better than having to write an auxilliary
predicate for each traced pure goal).

> > If you instead had
> > 
> > 	p(...) :-
> > 		trace([...],
> > 		      ( ... about to do q ... ),
> > 		      q(...),
> > 		      ( ... finished with q ... )),
> > 		trace([...],
> > 		      ( ... about to do r ... ),
> > 		      r(...),
> > 		      ( ... finished with r ... )).
> > 
> > then the trace goals would be reordered or eliminated with the pure
> > goals.
> 
> This approach would make it difficult to implement trace goals which, when
> enabled, you definitely don't want optimised away.

I'm not so sure it's any easier with single trace goals because of the
problems above.  Say you want to call q(...) but always print out a
message before and after, even if the call to q is optimized away.
Then if you also have a call to r, and you want the compiler to be
able to reorder the calls, you'll have to use one of your suggested
fixes, either wrapping the call to q and the two trace goals in a
promise_pure, or pushing them together into a separate predicate.
Either way, the trace goals disappear when the call to q is optimized
away.

There's a simple fix with the trace/4 approach:  also introduce a
similar always_trace/4 primitive.  It does the same as trace/4, but
keeps the trace goals around, somewhere in the clause, even if the
pure goal is optimized away.

-- 
Peter Schachte              In order to become the master, the politician
schachte at cs.mu.OZ.AU        poses as the servant.
www.cs.mu.oz.au/~schachte/      -- Charles de Gaulle 
Phone: +61 3 8344 1338      
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the reviews mailing list