[mercury-users] declarative kernels

Gustavo A. Ospina gos at info.fundp.ac.be
Wed Mar 8 21:33:21 AEDT 2000

>In my interpretation io__write is implemented as
>         io__write(X, State0, State) :-
>                 io__delay(State0, State1),
>                 io__really_write(State1, State2),
>                 io__delay(State2, State).
>and the effect of other programs modifying the world state between the
>two calls to io__write does not mean that IO1 has two different
>values at different times, it just means that inside the second
>call to io__write, the value of State0 is not the same as State1.

Ok, it's clearer for me now. This means the "precise instant" where the 
state is passed between the two io__write in my example is "atomic", there 
are not change of state in the transition.

io__delay can be seen like a relation between two "pictures" of the outside 
world, taken in two different times. What is required is the picture of the 
world that is passed in the transition between two IO operations should be 
the same.

Spawn threads would be an operation where the current picture of the world 
is given to the new threads. It can seem a duplication of the world, but 
it's not the case (just the pictures are duplicated). A model of 
concurrency with this model of IO should just assure that the global 
picture in the world is effectively passed between two IO operations, for 
every thread (there are a serialization, way the IO interactions).

In the model of io__state as list of interactions, it seems to me that the 
io__state is effectively duplicated when spawn threads, but i'm not totally 

BTW, I can't find references for 'spawn' when searching the mailing list.

+ Gustavo.

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

More information about the users mailing list