[mercury-users] Request for comments on this code

[Ian MacLarty]

On Wed, Jul 12, 2006 at 11:04:23AM +1000, Peter Schachte wrote:
> On Tue, Jul 11, 2006 at 08:42:08PM +1000, Ian MacLarty wrote:
> > On Tue, Jul 11, 2006 at 06:03:31PM +1000, Peter Schachte wrote:
> > > On Tue, Jul 11, 2006 at 01:32:03PM +1000, Ian MacLarty wrote:
> > > > On Tue, Jul 11, 2006 at 12:03:55PM +1000, Peter Schachte wrote:
> > > > > 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.
> 
> > > We need to thread the IO state through the code to keep the actions
> > > that effect the "state of the universe" in the right order.  So you
> > > don't want to consider too many things to be part of the "state of the
> > > universe," because you'll have to thread the IO state through
> > > everything that effects any of those things, at least if you care
> > > about the order they happen in.  You can't get around that by
> > > declaring that the state of the world psychically determines
> > > everything that's going to happen before the next IO action, including
> > > things inside Mercury, because that doesn't distinguish goals that
> > > cannot be reordered from goals that can.
> 
> > I don't really understand what you're saying.  I think what you're
> > saying is that my interprettation of the IO state means you can never
> > reorder any goals.
> 
> I'm just saying that you need to thread the IO state through all goals
> the order of whose effects on the state of the universe you care
> about, or else make them impure.
> As far as I can see, this is exactly
> the given wisdom about IO states and impurity.  For any operation
> whose effect on the state of the universe is commutative, such as
> making time pass*, the order of execution of that code is immaterial,
> so the IO state needn't be threaded through.
> 
> But as soon as you provide a way to fetch that part of the state of
> the world, such as reading the current clock time, the operations that
> effect that part of the state of the world are no longer commutative.
> Now you can tell the difference between
> 
> 	do_something,
> 	get_time(Time, !IO),
> 
> and
> 
> 	get_time(Time, !IO)
> 	do_something,
> 
> so the IO state needs to be threaded through do_something, and in fact
> through everything that could make an observable change to the state
> of the world.

No I disagree.  You could measure the effect of calling the procedure:

	do_something(T::in, T::out) is det

without threading the IO state through it as follows:

get_time(T0, !IO),
make_input(In, !IO),
do_something(In, Out),
consume_output(Out, !IO),
get_time(T, !IO)

In my interpretation you don't need to thread the IO state through
do_something/2, because make_input/3 has already updated the IO state to
take into account the effects of running do_something/2.

I believe that Ralph's interpretation is similar, but he uses one of the
calls to give_universe_a_turn to update the IO state with the effects of
running do_something/2 (Ralph please correct me if I'm wrong).

I don't see any worms in this view of things.

> 
> It's basically the same problem as tell and ask constraints.  As long
> as you only have tell constraints, they can happen in any order, so
> you don't need to thread the constraint store through them.  But as
> soon as you add an ask constraint, the order matters, and you have to
> thread the constraint store through everything.  Or you just make the
> ask constraint impure, so that's what we do.
> 
> Saying that at the previous IO operation the universe somehow knows
> what the state of the universe will be at the next operation doesn't
> solve the problem of telling *Mercury* what order to do things in.
> The IO state is threaded through to ensure that non-commutative
> operations (such as IO operations) happen in the right order.

I agree that using the IO state is not ideal for benchmarking things
(you might not always have input and output arguments like
do_something/2 above) and that using impurity (or trace goals, when we
get them) is a better solution for benchmarking.

My beef is with your argument that the IO state cannot contain things
that might be affected by the running of non-IO procedures in the
program.  Trying to work out what things can be affected by the running
of the program and what things can't is an impossible task.

I've already given the thermometer example.

Here's some others: Consider reading the size of a file.  I'm sure
you'd agree such a predicate could be pure if it took a pair of IO state
arguments?  Now what about reading the size of the swap file on windows?
When I run my program it may alter the size of the swap file.  So does
that mean I can read the size of all files except the swap file from the
IO state, but I have to use impurity to get the size of the swap file?
What about a program that takes a dump of the screen?  Is it only
allowed to get the screen dump from the IO state when the program itself
is not visible on the screen?

Do you agree that trying to exclude things that might be affected by the
running of the program from the IO state is ridiculous?

All I'm proposing is an interpretation of the IO state that allows
things that can be affected by the running of the program to also be in
the IO state.  So far I've had no problem with this interpretation.

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