[mercury-users] declarative kernels

[Ralph Becket]

> From: Fergus Henderson [mailto:fjh at cs.mu.OZ.AU]
> 
> On 07-Mar-2000, Ralph Becket <rbeck at microsoft.com> wrote:
> > My picture of an io__state is that it records a
> > *view* of the interface between a Mercury program
> > at some point and the outside world.  That is, it
> > records which files are currently opened by the
> > program, whereabouts the read/write cursor is for
> > each open file and so forth.  An io__state does 
> > *not* reflect the state of the outside world.
> 
> How then would you distinguish between the following
> two programs?
> 
> 	main --> print("yes\n").
> 
> 	main --> print("no!\n").
> 
> The position of the read/write cursor will be the same
> in both cases, the only difference is the state of the
> outside world (the contents of the screen, for example).

I see where the misunderstanding lies.  The program
interacts with its environment by carrying out IO operations;
it's io__state is updated as a function of its previous value,
the just executed IO op, and the `reply' from the environment.
Since the compiler can't predict how the io__state will be
changed after a given IO op, it can't transform a "yes"
program into a "no!" program (that is, print("yes") and
print("no!") are *different* IO ops).

The flaw in this picture is that it requires a `hidden'
notional state of the world, whereas taking an io__state to
actually be the state of the world means that a Mercury
program really is a relation between various world states,
with no need for auxiliary machinery.

> > - which
> > means that it sees file foo open at exactly the
> > same place.  Now, A and B can seek around quite
> > independently in foo without there being any
> > conflict since they are both evolving *separate*
> > io__states.
> 
> In my model, that might or might not be true, depending on whether
> threads have independent seek pointers for each I/O stream, or share a
> single seek pointer for each I/O stream.

Yes - I'd assumed the former, but as you point out,
there's no reason why that has to be the case.

Ralph
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------