[mercury-users] Request for comments on this code

Mark Brown mark at csse.unimelb.edu.au
Sun Jul 9 17:13:41 AEST 2006


On 09-Jul-2006, Peter Moulder <Peter.Moulder at infotech.monash.edu.au> wrote:
> You can force an ordering by using if-then-else: Mercury guarantees that
> the `if' goal is executed entirely before the `then' goal (modulo any
> backtracking).  We want R0 to be calculated before the solutions call,
> and the solutions call to be before R1, so we use two if-then-else's:
> 
>   ( clock(R0, !IO) ->
>   	( solutions(queens(N), Q) ->
> 		clock(R1, !IO),
> 		...
> 	 ; false
> 	)
>    ; false
>   )
> 
> (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),
	...

Failing this, if the operational semantics plays a part in the solutions
of a goal but is not reflected in the declarative semantics, then the code
is really impure and should be declared as such.

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

The labelling step is declaratively a NOP (and is perfectly pure), but you
always want it to be done after the constraints have been posted.  Moreover,
it is nondet so you can't thread the IO state through.  Currently, the
only options are to use impurity or to use the strict sequential semantics,
both of which have drawbacks.

Cheers,
Mark.

(*) There is a can of worms here regarding what IO states really mean.
But I'm not going to open it any further at this stage.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the users mailing list