[mercury-users] Request for comments on this code

[Peter Schachte]

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?  Or should && specify minimal
reordering:  only enough reordering across && to get the code moded
correctly?  It's not obvious to me whether that is well defined in all
cases.  Or is it weaker still:  don't reorder across && unless the
compiler has a good reason to think it would be a good idea?

I suspect the last of these is probably what you want.  It certainly
wouldn't be *wrong* to label first, and then add the constraints; it
just wouldn't be very efficient.  But maybe a really smart compiler
might figure out that the last constraint goal before the labelling
won't introduce any failures, so the labelling should be moved ahead
of it.  There's a trade-off between stopping the compiler from doing
stupid things and forbidding it from doing good things.

But my understanding of Mercury's default semantics is that when it
doesn't have a better idea, Mercury executes goals in the order the
programmer wrote them, so && wouldn't affect the behavior.  So unless
users want to start playing with funky different semantics, maybe we
don't need any special sequential conjunction at all.


-- 
Peter Schachte              What we are looking at is good and evil, right
schachte at cs.mu.OZ.AU        and wrong. A new world order!
www.cs.mu.oz.au/~schachte/      -- George Bush 
Phone: +61 3 8344 1338      
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------