[mercury-users] Request for comments on this code

[Peter Schachte]

On Tue, Jul 11, 2006 at 11:15:35AM +1000, Ian MacLarty wrote:

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

But any goal that might affect the IO state must thread the IO state
through.  If you consider the state of the Mercury process to be part
of the IO state, then *every* Mercury goal would need to thread the IO
state through.  And that means no goal reordering, and no
nondeterminism.  Otherwise in a goal

benchmark_something(X, Z, Time, !IO) :-
	time_consuming(X, Y),
	get_cpu_time(T0, !IO),
	something_to_benchmark(Y, Z, !IO),
	get_cpu_time(T1, !IO),
	Time = T1 - T0.

Mercury is perfectly entitled to move the call to time_consuming/2
after the first call to get_cpu_time/3.  I would also argue that if
something_to_benchmark/4 never affects the IO state, the compiler
should be allowed to remove the IO state arguments, and then should be
able to move the call to something_to_benchmark/2 anywhere it likes.
So while the IO state trick works now, keeping it working may limit
optimizations we may really want to implement someday.

I think it's pretty important to Mercury's IO state idea that the IO
state not be considered to include any artifacts of decisions made by
the Mercury compiler.  Otherwise the Mercury compiler cannot change
those things without affecting the correctness of the code.  I've
always heard the IO state referred to as the state of the world
*outside* of the current Mercury computation.

The idea of treating benchmarking as a special debugging-like
operation is much more attractive to me than making the IO state
contain the state of the internals of the current computation.  Or
using impurity should work, though there are still worms squirming
around where you promise the program pure.

-- 
Peter Schachte              The trouble with Communism is the Communists,
schachte at cs.mu.OZ.AU        just as the trouble with Christianity is the
www.cs.mu.oz.au/~schachte/  Christians.
Phone: +61 3 8344 1338          -- H.L. Mencken 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------