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

[Fergus Henderson]

On 12-Oct-2005, Julien Fischer <juliensf at cs.mu.OZ.AU> wrote:
> 
> On Wed, 12 Oct 2005, Ralph Becket wrote:
> 
> > Mark Brown, Wednesday, 12 October 2005:
> > > On 12-Oct-2005, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> > > >
> > > > Allow unifications to be delayed across impure goals.  Previously this
> > > > was disallowed which made it impossible to have deconstruction unifications
> > > > in impure pred calls, which was unnecessarily awkward.
> > > >
> > > > It is safe to reorder unifications across an impure goal because they cannot
> > > > be affected by the impure goal (unifications are pure).
> > >
> > > That doesn't follow!

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

> > What is an impure call allowed to do?  I think the side effects of
> > impure calls should be restricted to the hidden state.  An impure call
> > should not be allowed to, say, change the inst of a variable that is not
> > one of its arguments.
> >
> 
> I would intepret the reference manual as currently allowing that:
> 
> 	Impure predicates may perform I/O or modify hidden state,
> 	even if these side effects alter the operational semantics
> 	of other code.

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. 

-- 
Fergus Henderson                    |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------