[mercury-users] Request for comments on this code

[Ian MacLarty]

On Mon, Jul 10, 2006 at 06:18:48PM +1000, Peter Schachte wrote:
> On Mon, Jul 10, 2006 at 05:48:02PM +1000, Mark Brown wrote:
> > On 10-Jul-2006, Peter Schachte <schachte at csse.unimelb.edu.au> wrote:
> > > 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.
> 
> So the other processes running on the same machine are part of the IO
> state?  And the number of CPUs, the state of the caches, the number of
> other processes on the same machine?  How about thermal fluctuations
> that may cause the CPU to speed up or slow down?  The entire history
> of the universe is part of the state of the world?  That seems pretty
> ugly to me, semantically.
> 
> And anyway you still have the problem that if you consider time as
> part of the state of the world, and you make the philosphically
> dubious assumption that goals make time pass, then *every* Mercury
> predicate can affect the state of the world, and so really should
> thread an IO state.
> 

Mind if I try some of those worms?

I encountered this problem when I was first learning Mercury and came up
with the following interpretation of the IO state which satisfied me at
the time:

For every IO primitive executed in the program the first IO state
argument is the state of the universe at the time that IO primitive is
executed, while the second IO state argument is the state of the
universe at the time the *next* IO primitive is executed.  The first
argument of main/2 is thus the state of the universe at the time the
first IO primitive in the program is executed and the second argument is
the state of the universe when the program terminates (if main does
nothing then both arguments are the state of the universe at the time
the program terminates).

People may have problems with this view since it means the IO state must
also contain the state of the heap, stack, etc (since these, along with
the speed of the machine, ambient temperature, and position of the
planets, etc determine when exactly the next IO primitive will be
executed).  I don't really have a problem with this though.  So what if
a primitive IO action must also know when the next future IO action is
to be executed?  It's still deterministic with respect to the current
state of the universe since we can't go back in time.  Reasoning about
IO state this way allows you to measure the time taken by code that
doesn't execute any IO primitives.

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