[mercury-users] Request for comments on this code

[Julien Fischer]

On Mon, 10 Jul 2006, Peter Schachte wrote:

> On Sun, Jul 09, 2006 at 05:13:41PM +1000, Mark Brown wrote:
> > On 09-Jul-2006, Peter Moulder <Peter.Moulder at infotech.monash.edu.au> wrote:
> > > Mercury guarantees that
> > > the `if' goal is executed entirely before the `then' goal (modulo any
> > > backtracking).
>
> > > (I think that there was a proposal for a `&&' operator to make the above
> > > more readable; I can't remember the fate of that proposal.)
> >
> > It was deemed insufficiently useful at the time.  For cases like the above,
> > the idea would be to try to make explicit the IO states that you are
> > interested in (*).  So the code would look something like:
> >
> > 	clock(R0, !IO),
> > 	do_stuff(N, Q, !IO),
> > 	clock(R1, !IO),
>
> This is preferable to the if->then;else version, but still doesn't
> seem quite right semantically.  Being pure should mean the program
> behaves deterministically, and clock doesn't.  It also seems strage to
> thread the IO state through do_stuff if it doesn't do IO.  A smarter
> Mercury compiler could realize the subterfuge and decide do_stuff
> couldn't affect the IO state, and neither could clock/3, and so R1 =
> R0.  Better to make clock/3 impure, as Mark suggests later.
>
> > Having said that, I think we should re-open the case for `&&'.  It would
> > be particularly useful for applications that do constraint solving using
> > solver types.  For example, a typical application would do the following:
> >
> > 	post_constraints_1(...),
> > 	post_constraints_2(...),
> > 	...,
> > 	label_vars(...)
>
> Interesting point.  I never liked having if->then;else specify order
> dependence, since it interferes with making code multi-moded, and
> because it overloads one construct with two different purposes.  So I
> like the idea of an explicitly sequential conjunction.
>
> But what would it's meaning be?  Is it strictly sequential?  The
> compiler couldn't reorder across && even to mode the clause correctly?
> If so, where are function calls in the clause head put, at the end of
> the clause or at the beginning?

The compiler has to treat headvar unifications specially anyway.  Impure
goals in the body of a procedure cause a similar problem to the one you
have just described.

> Or should && specify minimal
> reordering:  only enough reordering across && to get the code moded
> correctly?

With the exception of reordering headvar unifications any other mode
reordering should result mode error - in fact it seems very similar
to how impure goals are handled now (minus the impure bit).

Julien.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at csse.unimelb.edu.au
administrative address: owner-mercury-users at csse.unimelb.edu.au
unsubscribe: Address: mercury-users-request at csse.unimelb.edu.au Message: unsubscribe
subscribe:   Address: mercury-users-request at csse.unimelb.edu.au Message: subscribe
--------------------------------------------------------------------------