[mercury-users] declarative kernels

[Fergus Henderson]

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

If the io__state does not contain the state of the
outside world, but only holds the read/write cursors,
then main/2 would define the same relation in both
cases, since for any given initial io__state the
two programs would both produce the same final io__state.

This would clearly be a problem, because we do not
want the compiler to be able to transform one of these
programs into the other!

> For example, if thread A has file foo open at some 
> point and then forks off a child thread B, B will
> start off with a *copy* of A's io__state

In my model, that is mostly true; 
the io__state passed to B will represent the
world external to that thread B, which will
be mostly the same as the world external to the
thread A (since most of the world is external
to both A and B).  However, there will typically
be some differences between the initial io__states
passed to each thread.

> - 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.  My model can handle both ways
of doing it.  In a practical implementation, either might apply, but I
suspect the latter is more likely.  (Tom Conway's implementation
of concurrent thread forking uses POSIX threads; I don't
know off-hand what POSIX specifies in this regard, but I think
it likely that the seek pointers are shared rather than duplicated.)

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------