[m-rev.] For review: allow unifications to be delayed across impure goals

[Zoltan Somogyi]

On 13-Oct-2005, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> Zoltan Somogyi, Wednesday, 12 October 2005:
> > On 12-Oct-2005, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> > > refer to any hidden state.  That leaves equality tests (so called
> > > complex unifications) which, if they mention arguments to the impure
> > > call, can only appear as implied modes
> > 
> > That is not true. A complex unification may involve terms of types with
> > user-defined equality such as solver types, whose implementation, while
> > presenting a pure interface, is impure.
> 
> Here's how I see it:
> 
> Consider a var/var unification appearing before an
> impure call.  There are three possibilities:

That is true, but that is not a rebuttal of what I wrote.

> (1) free/non-free: this is immediately scheduled as an assignment (i.e.,
> no delaying issue here);
> 
> (2) non-free/non-free: this is immediately scheduled as a complex
> unification (i.e., no delaying issue here);

It may be a simple unification.

> The wart I'm trying to fix is the case where we have something like
> 
> 	:- impure pred p(maybe(int)::in, maybe(int)::out) is whatever.
> 
> Currently I can't write a goal
> 
> 	impure p(yes(42), yes(X))
> 
> instead I have to draw an awkward distinction between input and output
> arguments for impure calls:
> 
> 	impure p(yes(42), Tmp), Tmp = yes(X)
> 
> This sort of thing turns up quite often in code using or implementing
> solvers.

The wart you are trying to fix is independent of solver types.

Zoltan.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------