[mercury-users] Request for comments on this code

[Ian MacLarty]

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

You say these are the only options.  What about threading some other
state that needn't be di, uo?  Wouldn't that also be an option?

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