[mercury-users] Request for comments on this code

Mark Brown mark at csse.unimelb.edu.au
Mon Jul 10 17:48:02 AEST 2006


On 10-Jul-2006, Peter Schachte <schachte at csse.unimelb.edu.au> 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.

Sure it does!  It just gets a different IO state as input every time it
is called, and the output is determined from that.

> It also seems strage to
> thread the IO state through do_stuff if it doesn't do IO.

The existence of clock/3 implies that the number of elapsed clock ticks
is part of the state of the world, and therefore the fact that do_stuff
takes a possibly non-zero amount of clock ticks to execute means that it
affects the IO state.  But this is getting perilously close to opening
the can of worms that I alluded to earlier.  :-(

Cheers,
Mark.

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