[m-dev.] for review: impure functions

[Tyson Dowd]

On 12-Apr-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > One outstanding open issue is that we don't specify what happens
> > when you put an impure call such as
> > 		
> > 		impure some_pred(foo(42), bar(17))
> > 
> > Where do the extra unifications get scheduled?
> 
> I think the unifications should get scheduled before
> the call to the impure procedure.  This is in accordance
> with the general principle that in the strict sequential
> semantics such unifications get executed depth-first,
> and that other semantics are based on the strict sequential
> semantics with additional reordering allowed but not over
> impure goals.

Does the strict semantics option really order unifications like this?
The code looked like it always did unifications in the reverse order.

> I think the code that you posted this time does the right thing
> with regard to this issue.

I think the implementation is right (now), it's just not specified.
Being not specified, when I went to extend the implementation I
got it wrong the first time. 

> > -Pure predicates and functions always return the same outputs given the
> > -same inputs.  They do not interact with the ``real'' world (i.e., do any
> > +For pure procedures, the set of solutions depends only on the
> > +values of the input arguments.
> > +They do not interact with the ``real'' world (i.e., do any
> >  input/output) without taking an io__state (@pxref{Types}) as input and
> >  returning one as output, and do not make any changes to any data
> >  structure that will not be undone on backtracking (unless the data
> >  structure would be unreachable on backtracking).  The behaviour of pure
> >  predicates is never affected by the invocation of pure predicates.
> > -It is possible for the invocation of pure predicate to affect the
> > +It is possible for the invocation of pure predicates to affect the
> >  behaviour of non-pure predicates and vice versa.
> 
> I would prefer just dropping the last two sentences.
> But that is an existing flaw, not something introduced
> by this change, so I don't mind if you go ahead and commit
> this change without fixing that; we can debate that point
> at length ;-)

Ok.  I'll keep it for now.


I've made the other changes and will commit soon.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------