Type in a program into the java applet; then click the Step button several times to watch it execute! Here are two example programs you might try:
|
rsh<ls> | rsh(y).y<> |
Send the message ls over channel rsh. Meanwhile, in parallel, listen on channel rsh and execute the command y that we receive. |
| null<x> | !null(y) |
Send the message x over channel null. Meanwhile, in parallel, listen repeatedly on channel null and simply do nothing with everything that we receive. |
P ::= x<y>.P or x!y.P output
x(y).P or x?y.P input of bound or free name
P | Q two things running concurrently
(x)P name x is local
x=y explicit fusion
!P replication
0 nil process
The machine performs reaction steps -> and some internal equivalence steps ===, generally to do a substitution or split up two parallel terms or create a fresh channel. Note: channel-names in the original program source code (i.e. as text) are represented as you typed them in. But once the channel has been physically created, then this is very different from a piece of source code: we represent this by changing its case.
This is a distributed abstract machine to implement the pi calculus and the explicit fusion calculus.
The pi calculus uses synchronous rendezvous, which is considered hard to implement in a distributed way. The join calculus was invented with an alternative mechanism for interaction, designed to be easier to implement (Fournet, Gonthier, Levy). There is an encoding of the pi calculus into the join calculus. There has been one other distributed implementation of the pi calculus, Facile, which integrates it with the lambda calculus.
The standard implementation of synchronous rendezvous, used in both Facile and the join calculus encoding, is as follows. One program sends an out message to a channel-manager; another sends an in message; and then the channel-manager sends back two continue messages to allow the programs to continue.
But in many cases - and in all pi calculus programs - it does not actually matter where the continuing program should execute. We will use this fact as follows. Let the two programs send entire continuation closures along with their out and in messages. (A closure comprises both program code and current state.) Then the channel-manager can execute the continuations in place; it does not have to send back any messages.
Now Cardelli has proposed a non-distributed abstract machine for synchronous rendezvous, which has been used in two implementations---Pict and Squeak. Using continuations as described above, it is easy to make Cardelli's machine distributed. This makes for an implementation of the pi calculus that is straightforward to implement and to reason about. However, it has the problem that the continuation messages might potentially be large. We solve this problem through a combination of the solos calculus (Laneve, Victor) and the explicit fusion calculus (Gardner, Wischik).
Note: We've taken a few shortcuts in the java applet above. Instead of being distributed between machines, it is only distributed among threads. And instead of being distributed among threads, it just gets executed in turn by a single thread. Fairness is not implemented.
@Misc{wischik_fmprototype,
author = "Lucian Wischik",
title = "Fusion Machine Prototype",
year = 2002,
howpublished = "http:// www.wischik.com/ lu/ research/ fusion-machine",
}