Work in progress. 2000-2002.

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.Poutputx(y).P or x?y.Pinput of bound or free nameP | Qtwo things running concurrently(x)Pname x is localx=yexplicit fusion!Preplication0nil 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", }