Co-ordination languages ...

Michael David WINIKOFF
Sat, 13 Mar 93 23:09:58 EST

Hi people!
I've just read the co-ordination paper (CACM, Feb 1992) and have followed the
debate backwards (April and OCtober 1989 CACMs)

The coordination language proposed in the paper is Linda.

Linda has the following primitives:

out(tuple) in(tuple) rd(tuple) inp(tuple) rdp(tuple) eval(tuple)

out places a tuple into "tuple space"
in gets a tuple from tuple space.
Note that in uses a form of pattern matching:


in("V",? i, ? f)

f is assigned to 2 and i to 1.

in removes the tuple whereas rd doesn;t.
The "p" versions of in and rd (read) return imediately if there is no such tuple
available whereas "in" and "rd" suspend.

eval creates a process to evaluate the tuple b4 outing it.

out(some_fun(3)) will evaluate some_fun then do the out.
eval(some_fun(3)) will return immediately, some_fun will be evaluated in a new
process and when completed the tuple will be available.

THe debate was centered about parallelism -- mostly irrelevant for our purposes.

The points that concern us are:
(1) Linda enables cross language work.
(2) An OS defines a co-ordination language.
(3) A coordination language is a uniform framework for inter application, 
inter time (ie. communicating with future programs -- normally done through
files) and I/O
(4) there is a problem with having a single tuple space -- The people working
on Linda have defined multiple tuple spaces and ways of treating them as first 

What I would like to propose based on this is NOT that we adopt linda but rather
that we use it's simplicity as a guide in seeking a single unifying 
concept encompassing files, inter application communication and inter machine

Since an OS defines a coordination language we can implement this concept as
a conventional OS -- the problem with current OSes is that they use many 
seperate concepts for these things (eg., files., shared memory, RPC etc.)


Michael Winikoff
Computer science honours. University of Melbourne, Australia.