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

[Ralph Becket]

Fergus Henderson, Wednesday, 19 October 2005:
> Yes.  Some impure calls may affect pure unifications (e.g. consider
> Prolog's setarg/3, or it's Mercury equivalent in
> samples/trailed_update/var.m).  Furthermore, even if the pure
> unification is not affected by the impure goal, that doesn't
> necessarily mean that the two goals can be safely reordered, because
> the impure goal might be affected by the pure unification (e.g.
> consider Prolog's var/1).

This is all well and good, but the mode system prevents these issues
from arising.  During normalisation a goal is flattened so that any
argument unifications are listed before the "top-level" call in the
goal.  During mode analysis we delay a goal only if it cannot be
scheduled immediately.  Therefore any argument unifications for an
impure call that *can* be scheduled before the impure call *will* be
scheduled before the impure call.  The only argument unifications
that are *not* scheduled before the call are those that *cannot* be
scheduled before the call because some of the variables involved
have yet to become non-free.  There is therefore *no* choice in the
matter: these unifications must come after the call.

The current situation is that for impure calls we can put expressions
in input argument positions, but only distinct variables in output
argument positions, which we then have to explicitly deconstruct (or
whatever).  IMHO this is both ugly and unnecessarily verbose.

One other point: with impure code it is the programmer's responsibility
to ensure that calls are made in the right sequence.  The situation is,
I claim, analagous to writing code like `X \= 0, Z = Y / X' to avoid a
division-by-zero exception.  The *correct* thing to do here is to use an
if-then-else to ensure the test for X is executed before the division.
Similarly, if one really really does care about the relative order of
a unification and an impure call, one should write the unification as a
separate goal in the right place (and not as an argument to the impure
call).

> Yes.  "impure" was intended to support operations similar to
> Prolog's var/1, write/1 (including the case where the argument
> to write/1 is free or partially instantiated), setarg/3, etc. 

This does not apply here because `free' and `any' are quite different
things.  You can implement var/1 for inst `any' arguments, but there is
no inst that denotes `either free or non-free'.

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