[mercury-users] declarative kernels

[Fergus Henderson]

On 06-Mar-2000, Thomas Conway <conway at cs.mu.OZ.AU> wrote:
> On Sat, Mar 04, 2000 at 12:01:15PM EST, Michael Day wrote:
> > 
> > given the recent discussion of coroutines and concurrency, does anyone
> > have any references to declarative operating system kernels, or work being
> > done in this area?

>From what I've heard, there's been quite a bit of work done in this area,
much of it a fairly long time ago, before the Mercury project began.
In particular I believe the concurrent logic languages and perhaps the
Japanese 5th generation project may have done work on this.
I don't have any specific references off-hand, but if you want more
information, you could try asking in comp.lang.functional, comp.lang.prolog,
comp.os.research, or somewhere like that.

This question is a far more general question than the one you ask below.

> > What exactly does io__state represent, when it's being
> > passed to multiple programs by another underlying program?
> 
> There are two interpretations of the io__state.
> 
> The first, proposed by Fergus, is that the io__state represents the state
> of the external world, and that I/O operations modify the external state.

Note that in the context of concurrent threads, "external" here should mean
"external to the current thread", not "external to the program".
This is an important distinction.

> This has the drawback that if, for example someone else on the system
> removes a file between when you finished writing it, and when you go to
> read it again, then the act of closing the file has to implicitly remove
> it as well, which is a bit strange, but it is a fairly simple model.

The semantics of every primitive I/O operation is:

	- delay for some unspecified period of time
	  (during which the state may change due to the effect
	  of other threads, other processes, etc.)
	- then perform the primitive I/O operation
	- then delay for another unspecified period of time

It's safe to simplify this slightly by omitting either the first
delay or the second delay (but not both!), so long as you do so
consistently.  But I think it is easier to think about if you
omit the second delay, rather than omitting the first.
In that case, for your example, it would be the second call to `open'
(to read the file again) which would account for the effects
of other processes in between the `close' and then second `open',
and so those effects would be associated with the second `open',
not with the `close'.

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