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

Ralph Becket rafe at cs.mu.OZ.AU
Thu Oct 13 11:48:14 AEST 2005


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:

(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);

(3) free/free: this *has* to be delayed until at least one of the vars
becomes non-free, but there is no choice about this.

So the only case we have to worry about here is (3), where I can't see
any problem.

Next, consider a var/functor unification appearing before an impure
call.  The only way we can get a delayed complex unification out of this
is if (at the point the var/functor unification is encountered by the
mode checker) the var is free and the functor contains at least one free 
argument.  Again, since this *has* to be scheduled after the impure
goal, where is the problem?



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.

-- Ralph
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the reviews mailing list