[mercury-users] Request for comments on this code

[Ian MacLarty]

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.  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).
> 
> If you take that view, then you really don't need to thread the IO
> state anywhere, since the IO state after a call to an IO primitive
> holds the state of the world at the time of the next IO primitive,
> including anything I might read from or write to IO streams.
> 

But you have to use an IO primitive to read or write from a stream.

> 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 don't agree with you if that's what you're saying.
Any I/O primitive has all it needs to know to predict what the state of the
universe will be when the next IO primitive is called and that's all
that matters (I'm assuming a deterministic universe here, which for our
purposes I think is fine).  This interpretation is all we need to give a
declarative meaning to the IO state.  The fact that the running of
non-IO Mercury predicates affects what the IO state at the next IO
primitive will be doesn't matter - that's already been taken into
account by the previous IO primitive.  Non-IO calls can be reordered and
there's still no problem, since the previous IO primitive will know
about the reordering.

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