Computer science aims to explain the way computational systems behave for us. The notion of calculational process, or algorithm, is a lot older than computing technology; so, oddly enough, a lot of computer science existed before modern computers. But the invention of real stored-program computers presented enormous challenges; these tools can do a lot for us if we describe properly what we want done. So computer science has made immense strides in ways of presenting data and algorithms, in ways of manipulating these presentations themselves as data, in matching algorithm description to task description, and so on. Technology has been the catalyst in the growth of modern computer science.

The first large phase of this growth was in free-standing computer systems. Such a system might have been a single computer program, or a multi-computer serving a community by executing several single programs successively or simultaneously. Computing theorists have built many mathematical models of these systems, in relation to their purposes. One very basic such model - the λ-calculus - is remarkably useful in this role, even if it was designed by Alonzo Church around 1940.

The second phase of the growth of computer science is in response to the advent of computer networks. No longer are systems freestanding; they interact, collaborate and interrupt each other. This has an enormous effect on the way we think about our systems. We can no longer get away with considering each system as sequential, goal-directed, deterministic or hierarchical; networks are none of these. So if we confine ourselves to such concepts then we remain dumb if asked to predict whether a network will behave in a proper - or an improper - way; for example, whether someone logging in to his bank may (as happened recently) find himself scanning someone else's account instead of his own.

The present book is a rigorous account of a basic calculus which aims to underpin our theories of interactive systems, in the same way that the λ-calculus did for freestanding computation. The authors are two of the original researchers on the π-calculus, which is now over ten years old and has served as a focus for much theoretical and practical experiment.

2.1 Strong barbed congruence

This section begins to develop the theory of behavioural equivalence by introducing strong barbed bisimilaritv and strong barbed congruence. The former is defined via a kind of bisimulation involving internal action and a notion of observation. Two terms are strong barbed congruent if the processes obtained by placing them into an arbitrary context are strong barbed bisimilar. The barbed bisimilaritv and congruence are strong in that they take processes to evolve only in single Ƭ transitions: there is no provision for abstraction from the number of Ƭ transitions that comprise an evolution. When such provision is made, we obtain (weak) barbed bisimilaritv and barbed congruence, the latter being the relation we adopt as the principal behavioural equivalence for π-terms throughout the book. These relations will be introduced in Section 2.4.

We begin by introducing strong barbed bisimilaritv. Consider first the following two-plaver game on the directed graph whose nodes are the processes and whose arrows are given by the Ƭ-transition relation. The players move alternately. A play either is infinite, or in its final position the player whose turn it is cannot move. A play begins with two nodes occupied by tokens. The first player can move either of the tokens from the node it is on along an outgoing edge to a neighbouring node. The second player can respond only by moving the other token from the node it is on along an outgoing edge to a neighbouring node. If a play is infinite then the second player wins. If after some finite number of moves the player whose turn it is cannot move, then that player loses.

For given starting processes, the second player has a winning strategy for the game iff the processes are reduction bisimilar, that is, they are related by a bisimulation on the graph.

Mobile systems are everywhere. Palpable examples are mobile communication devices and the networks that span the Earth and reach out into Space. And less tangibly, there is mobile code and the wondrous weaving within the World Wide Web. An accepted science of mobile systems is not yet established, however. The development of this science is both necessary and challenging. It is likely that it will consist of theories offering explanations at many different levels. But there should be something basic that underlies the various theories.

This book presents the π-calculus, a theory of mobile systems. The π-calculus provides a conceptual framework for understanding mobility, and mathematical tools for expressing mobile systems and reasoning about their behaviours. We believe it is an important stepping-stone on the path to the science of mobile systems.

But what is mobility? When we talk about mobile systems, what are the entities that move, and in what space do they move? Our broad answer is based on distinguishing two kinds of mobility. In one kind, it is links that move in an abstract space of linked processes. For example: hypertext links can be created, can be passed around, and can disappear; the connections between cellular telephones and a network of base stations can change as the telephones are carried around; and references can be passed as arguments of method invocations in object-oriented systems. In the second kind of mobility, it is processes that move in an abstract space of linked processes. For instance: code can be sent over a network and put to work at its destination; mobile devices can acquire new functionality using, for instance, the Jini technology [AWO+99]; and procedures can be passed as arguments of method invocations in object-oriented systems.

The π-calculus treats the first kind of mobility: it directly expresses movement of links in a space of linked processes. There are two kinds of basic entity in the (untyped) π-calculus: names and processes. Names are names of links. Processes can interact by using names that they share. The crux is that the data that processes communicate in interactions are themselves names, and a name received in one interaction can be used to participate in another.

Subtyping is a preorder on types that can be thought of as inclusion between the sets of the values of the types. If S is a subtype of T then a value of type S is a also a value of type T. For instance if Nat, Int, and Real are the types of natural numbers, integers and reals, respectively, then we could naturally stipulate that Nat is a subtype of Int and that Int is a subtype of Real.

If S is a subtype of T then an expression of type S can always replace an expression of type T; if the program before the replacement is well typed, then also the program after the replacement will be so. This is so because the operations available on values of type T - both the pre-defined and the user-defined operations - are also available on values of type S. For instance, operations such as multiplication and division that are available on Real are also available on Int. The converse, by contrast, may be false; for instance on Int there are operations like successor and predecessor that do not make sense on Real. The possibility of having operations that work on all subtypes of a given type is a major advantage of subtyping in a programming language. (In the implementation of programming languages, the subtyping from integers to reals requires a conversion that modifies the representation of a number; therefore operations defined on both types will have different implementations for the two types. Due to this non-uniformity, the subtyping between integers and reals is called ‘ad hoc’ subtyping. In general, all subtyping between basic types is ad hoc. The subtyping on structured types - the non-basic types - that will be presented in this section is, by contrast, uniform.)

Programming language constructs that are usually associated with subtyping are records, variants, and objects. Subtyping is a key feature of object-oriented languages (perhaps the key feature). Indeed, the study of subtyping and of the associated programming constructs has been motivated mainly by the interest in object-oriented languages.

11.1 Some properties of linearity

We present some behavioural properties of linear types, on the polvadic π-calculus with i/o and linear types, π. First, as linear types refine i/o types, behavioural equivalences that are true with i/o types are also true with linearity.

Exercise 11.1.1

Lemma 11.1.2 shows that communications along linear names are Ƭ-insensitive, that is, they do not affect behaviour, under the condition that such communications do not involve sum. Ƭ-insensitivitv is a useful property: when comparing the behaviour of two processes there are fewer configurations to take into account.

Proof (Sketch) Under the hypothesis of the lemma, it must be, for some z, T, x, S, v, y, P1, P2, and P3, that

and then the assertion of the lemma is an application of the π-calculus law

This law is valid in untyped or simply-typed π-calculus (it is an immediate consequence of Corollary 2.4.19(1)), hence also with linear types, by Exercise 11.1.1(2).

Using linearity, in the Asynchronous π-calculus the following law - the linear version of law (10.3) - is valid for barbed congruence:

11.2 Behavioural properties of receptiveness

We will not dwell on the details of the behavioural theory and proof techniques for receptive types. We present only a few key laws, some of which (law (2) of Lemma 11.2.1 and law (2) of Lemma 11.2.4) transform external mobility into internal mobility. The combination of these laws with standard proof techniques of the π-calculus, such as bisimilaritv, gives us a powerful proof method for establishing behavioural properties involving receptiveness, essentially the analogue for receptiveness of the proof method for i/o types examined in Section 10.8. We will see this method at work later in this section, and in Sections 13.2.5 and 20.3.

Object-oriented programming is widely practised. It is based on an analogy between concrete physical models, built from real objects, and abstract software models, whose components are intangible computational entities - an example being a physical model of an aircraft wing, for testing in a wind tunnel, and a software model of the wing, for testing by computer simulation. Following the analogy, the intangible entities that comprise the software models are themselves called objects. In general, as an object-oriented system evolves, objects are created and the interconnection structure among objects changes. Although some implementations of object-oriented programming languages are sequential, activity within a system of objects is naturally thought of as concurrent.

This final Part of the book is about how π-calculus can be useful in object-oriented design and programming. The most important point is an indirect one. It is that a good theory offers a conceptual framework, a way of thinking about design and analysis of systems that helps one see the wood as well as the trees. The π-calculus captures in a tractable mathematical form a particular conception of mobile system. That conception is closely related to ideas that are important in object-orientation, especially its behavioural aspects. It may also be that particular concepts from π-calculus can usefully be transferred to objects, for instance ways of understanding behaviour, analytical techniques, type constructs, and process operators.

The π-calculus can be used to express systems of objects mathematically. This modelling can be carried out at all points on the spectrum from design-sketch to implementation in a programming language. And π-calculus techniques can be used to reason about object systems, both their static aspects, for instance types, and their dynamic properties.

Part VII illustrates some of these points by giving a semantic definition for a simple object-oriented language by translation to the π-calculus, and using techniques from earlier in the book to show some properties of the language and programs written in it.

The requirements placed on π-calculus descriptions may vary from one region of the design-implementation spectrum to another. At the design-sketch end, an informal understanding of the notation or language used may be sufficient to grasp the accuracy of π-calculus descriptions. Indeed, the act of modelling may help to sharpen understanding.

13.1 Compiling higher order into first order

Passing processes looks like a drastic departure from passing names. We show in this section and the next, however, that process-passing can be faithfully compiled down to name-passing. We present two main compilations. The second is an optimization of the first. Moreover, the second, unlike the first, is also defined on calculi with recursive types. However, the first compilation is mathematically easier to work with.

We begin with the first compilation, which we call D. The communication of a higher-order value v is translated as the communication of a private name that acts as a pointer to (the translation of) v and that the recipient can use to trigger a copy of (the translation of) v, with appropriate arguments. For instance a process is translated to the process a recipient of the pointer y can use it to activate as many copies of as needed, with appropriate arguments. The compilation separates the acts of copying and of activating the value (x).R; copying is rendered by the replication, and activation by communications along the pointer y. Here are some simple examples of how the compilation works. We omit, for now, all type annotations.

In the example above, it is important that the trigger name y is private: if it were not, a process in the surrounding environment could interfere with the second communication step.

The examples above show translations of applications vw in which v is a name; in this case the application is translated in the same way as an output vw. Here is an example in which v is an abstraction (it is similar to Example 13.1.1, except that (z). R is the argument of an application, rather than the value being output):

The compilation modifies types: a name used in HOπ to exchange processes becomes, in π-calculus, a name used for exchanging other names. The definition of the compilation on types, type environments, values, and terms is given in Table 13.1.

The local structure of the π-interpretation, =π, is the behavioural equivalence induced on λ-terms by their encoding into π-calculus. In the previous chapter we proved a characterization of =π as the operational equivalence of extended λ-calculi. We continue the study of =π in this chapter, with the purpose of understanding the meaning of function equality when functions are interpreted as processes. We will prove characterizations of =π in terms of tree structures that are an important part of the theory of the λ-calculus. This will show that the equivalence induced by the π-calculus encoding is a natural one. It will also show the utility of some of the π-calculus proof techniques of Section 2.4.3: using techniques such as ‘bisimulation up to context’ and ‘bisimulation up to expansion’, the proofs of the main theorems will be much easier than they would have been otherwise.

The main result says that =π coincides with LT equality, whereby two λ-terms are equal iff they have the same Lévy-Longo Trees. Lévy-Longo Trees are the lazy variant of Böhm Trees. We will also discuss modifications of the π-calculus interpretation so that its local structure is the analogous BT equality. We begin by recalling what LTs are. A reader familiar with them may go straight to Theorem 18.3.1.

We maintain Notation 17.1.1 throughout the chapter.

18.1 Sensible theories and lazy theories

Böhm Trees (BTs) are the best-known tree structure in the λ-calculus. BTs play a central role in the classical theory of the λ-calculus. The local structure of some of the most influential models of the λ-calculus, like Scott and Plotkin's Poj, Plotkin's T, and Plotkin and Engeler's DA, is precisely the BT equality; and the local structure of Scott's D (historically the first mathematical, i.e., non-svntactical, model of the untyped λ-calculus) is the equality of the ‘infinite η contraction’ of BTs.

BTs naturally give rise to a tree topology that has been used for the proof of some seminal results of the λ-calculus such as Berry's Sequentiality Theorem. BTs were introduced by Barendregt [Bar77], and so called after Böhm's theorem and proof about separability of λ-terms. The proof technique for this theorem, called the Böhm-out technique, roughly consists in finding a context capable of isolating a given subtree of a BT; in this way, certain λ-terms that have different BTs may be separated.

9.1 Using types to obtain encapsulation

It is desirable that a language, whether sequential or parallel, should have facilities for encapsulation, that is, features that make it possible to constrain access to components such as data and resources. The need for encapsulation led to the development of abstract data types. Encapsulation is also a key feature of objects in object-oriented languages.

In CCS, encapsulation is achieved by the restriction operator. Restricting a name x on a process P, written (using π-calculus notation) vx P, guarantees that interactions along x between subcomponents of P occur without interference from outside. For instance, suppose we have two 1-place buffers, Buf1 and Buf2. Suppose Buf1 receives values along a name x and resends them along y, whereas Buf2 receives at y and resends at z. They can be composed into a 2-place buffer that receives at x and resends at z thus: vy (Buf1 | Buf2). Here, the restriction ensures that actions at y from Buf1 and Buf2 are not consumed by the external environment. With the formal definitions of Buf1 and Buf2 at hand, one can indeed prove that the system vy (Buf1 | Buf2) is behaviourally equivalent to a 2-place buffer.

The restriction operator provides a quite satisfactory level of protection in CCS, where the visibility of names in processes is fixed. By contrast, restriction alone is very often not satisfactory in the π-calculus, where the visibility of names can change dynamically. Here are two examples.

Example 9.1.1 (A printer with mobile ownership) Consider a situation in which several client processes cooperate in the use of a shared resource such as a printer. Data are sent for printing by the client processes along a name p. Clients can also communicate name p so that new clients can get access to the printer. Suppose that initially there are two clients

and therefore, writing P for the printer process, the initial system is

One might wish to prove that when Cl's print jobs, represented by j1 and j2, are delivered, they are received and processed in that order by the printer.

Part I introduces the π-calculus. It explains how the terms of the calculus describe the structure and the behaviour of mobile systems. It also develops the basic theory of behavioural equivalence, and introduces basic techniques for reasoning about systems.

How system behaviour is expressed is fundamental to the theory. Two accounts of behaviour will be given. The first explains how a system represented by a π-calculus term can evolve independently of its environment. At the heart of this first account is a binary relation on terms called reduction. The second account explains not only activity within a system but also how the system can interact with its environment. Central to it is a labelled transition system on terms.

Why are there two accounts of behaviour? The reason is that each has useful qualities that the other lacks. Reduction explains activity within systems in a way that overcomes the rigidity of linear syntax. This makes the account based on reduction easy to grasp, something that is helpful when the π-calculus is encountered for the first time. Reduction has two related limitations, however. First, it does not say how a system can interact with its environment. And second, the free treatment of syntax, which helps to make the account simple, also makes it difficult to prove things about behaviours. The account based on transition overcomes both of these limitations, but at the unavoidable cost of a little increase in complexity. It explains both activity within a system and interaction between a system and its environment by describing the actions that processes can perform. And it explains action in a way that is guided by the syntax of terms, so that, in particular, the structure of proofs can follow the syntax.

Reduction is a relation of a kind familiar from term-rewriting systems, while labelled transition systems are well known from process calculi. In term-rewriting systems, the definition of the reduction relation is relatively straightforward because a redex of a term must be a subterm. For example, in the λ-calculus - perhaps the best-known term-rewriting system - in order for a function to be applied to an argument, the two must be contiguous.

A type system is, roughly, a mechanism for classifying the expressions of a language. Type systems for programming languages, sequential and concurrent, are useful for several reasons, most notably:

• (1) to detect programming errors statically

• (2) to extract information that is useful for reasoning about the behaviour of programs

• (3) to improve the efficiency of code generated by a compiler

• (4) to make programs easier to understand.

Types are an important part of the theory and of the pragmatics of the π-calculus, and they are one of the most important differences between π-calculus and CCS-like languages. Many of the type systems that have been studied for the π-calculus were suggested by well-known type systems for sequential languages, especially λ-calculi. In addition, however, type systems specific to processes have been proposed, for instance for preventing certain forms of interference among processes or certain forms of deadlock.

In the book we will be mainly interested in the purposes (1) and (2) of types; purposes (3) and (4) are more specific to programming languages (as opposed to calculi). In this Part of the book we introduce several important type systems and present their basic properties. In the next Part we study the effect of types on process behaviour and reasoning.

We formalize type systems by means of typing rules. The terms that can be typed using these rules are the well-typed terms. The most fundamental property of a type system is its agreement with the reduction relation of the calculus, the subject reduction property. A consequence of this property is type soundness, asserting that well-typed processes do not give rise to run-time errors under reduction. We use a special term wrong to represent a process inside which such an error has occurred. Therefore, type soundness will mean that a well-typed process cannot reduce to a process containing wrong.

We discussed run-time errors informally in Section 3.1, when we introduced the polvadic π-calculus. There, we used sorting as a mechanism for avoiding errors. Sorting is an example of a type system where equality between types is by name, as opposed to by structure. In the by-name approach, each type has a name (a sort, in the case of a sorting), and two types are equal if they have the same name. In the by-structure approach, two types are equal if they have the same structure.

This chapter illustrates some uses of the kind of semantic definition given in Chapter 19 via a series of examples. We continue to use the notations in Notation 19.2.1.

20.1 Some properties of declarations and commands

Example 20.1.1 (Eliminating an unused variable) Consider the skeleton class declaration in Table 20.1. If none of Ci,…, C*, contains either the expression X or a command of the form X := E, then deleting the declaration of X should not change the behaviour of objects of the class, and hence should not affect the behaviour of any program in which the class appears. To prove this, we use the straightforward equivalence

provided. (For notational convenience, in what follows we assume that T is Int.)

Now suppose that X is the jth variable of A, and write Vj for V〈gj, pj, 0〉 and abbreviate gj to g and pj to p. Then there are processes G and P such that

Let A’ be the class obtained from A by deleting the declaration of X. Then, since none of the method bodies contains the expression X or an assignment to X,

Hence

using (20.2), the equivalence in (20.1), and the observation in (20.3). This completes Example 20.1.1.

Example 20.1.2 (Replacing a variable by a constant) Consider again the skeleton class declaration in Table 20.1. If none of C1,… ,Ck contains a command of the form X : = E, then replacing each occurrence of the expression X in C1,…, Ck by 0 (the initial value of X) and deleting the declaration of X should not change the behaviour of objects of the class, and hence should not affect the behaviour of any program in which the class appears.

Let us reuse the notations Vj, MA, etc. from Example 20.1.1, and write A” for the class obtained from A by applying the transformation.