In the first half of this chapter, comprising Sections 10.1-10.5, we discuss the consequences of i/o types for behavioural properties of processes. For this, we compare the polvadic π-calculus (π) with the polvadic π-calculus with i/o types (π). In the former calculus the only constraint that types impose is that arities of names must be respected; in the latter, i/o information is also taken into account. In the second half of the chapter, comprising Sections 10.6 to 10.8, we study techniques for proving behavioural equivalences that crucially rely on the i/o constraints.

10.1 Type coercion

We first show that if processes of π are equivalent when i/o information is forgotten, then they are also equivalent in π, where by ‘forgotten’ we mean that all i/o types are coerced to connection types. The result is useful because proving equivalences in the π-calculus with only the connection type is easier (for instance, the definition of typed bisimilaritv is simpler).

The reason why Theorem 10.1.1 holds is that in π the coercion of i/o to connection types preserves type judgments. This may however be false in calculi with a richer subtyping relation:

Exercise* 10.1.2 Show that Theorem 10.1.1(1) fails in π where tuple types are replaced by records.

Most important is the behavioural effect of the refinement of connection types to i/o types. Processes that are distinguishable in π may become equivalent when types are so refined. The equivalences so gained are often highly desirable. In Section 10.2 we present five concrete examples of such equivalences. Then, in Sections 10.3 and 10.5, we present two very useful results: a law about wire processes in the Asynchronous π-calculus, and the Sharpened Replication Theorems. The equivalences in the examples and the results will be proved in the second half of the chapter. In Section 10.4 we exploit the wire processes and their laws to model the delayed input construct, in the Asynchronous π-calculus. More examples of the use of i/o types for reasoning can be found in Parts V and VI; see Theorem 13.2.22 and discussion afterwards, and Remark 15.3.17.

3.1 Polyadicity

In the monadic π-calculus, an interaction involves the transmission of a single name from one process to another. A natural and convenient extension is to admit processes that pass tuples of names. The enriched language, the polvadic π-calculus, is examined in this section.

Definition 3.1.1 (Polyadic π-calculus) The processes of the polyadic tt- calculus are defined in the same way as the processes of the monadic calculus, except that the prefixes are given by

where no name occurs more than once in the tuple z in an input prefix.

The intended interpretations of the new polyadic prefixes are that. P can send the tuple via x and continue as P, and that. Q can receive a tuple via x and continue as.

The natural way to extend the reduction relation to polyadic terms is to change the first axiom, R-inter, of reduction to:

Thus, in an interaction, sender and receiver must agree on the length of the tuple to be passed. (We write | x | for the length of the tuple x.) Simply defining reduction using Pr-inter is not the end of the story, however.

To see why, consider a polyadic term in which sender and receiver disagree on the length of tuple to be transmitted via some name, for instance,

A term such as this is somewhat analogous to an ill-tvped application term in a typed λ-calculus. It may not be manifest whether a disagreement of the kind illustrated in (3.1) can arise from a given polvadic process. For instance,

can evolve in two reductions to the term in (3.1); and one can easily imagine more complicated examples.

How can such ill-formed polvadic processes be separated out? Taking a cue from λ-calculus and programming languages, we may seek to achieve the separation via a suitable type discipline. Part III and Part IV are devoted to types, and consider in particular typing of polvadic processes. Passing of tuples is so useful, however, that we wish to anticipate a little and develop a suitable treatment here. The treatment will use a by-name typing discipline, based on sorts. The typing is by name in that different sorts are considered to be different types. From Part III on, we study typing by structure, where types are equal if they have the same structure.

14.1 The formal system

The beauty of the λ-calculus is that it achieves Turing completeness - all computable functions are definable in it - with a very simple syntax. The basic operators of the λ-calculus, in its pure form, are λ-abstraction, for forming functions, and application, for applying a function to an argument. A λ-abstraction has the form λx. M: in the body M of the function, the variable x is a place-holder for the argument. (We stick to the standard λ-calculus terminology, and call x a variable, rather than a name.) Letting x and y range over the set of λ-calculus variables, the set Λ of λ-terms is defined by the grammar

In λx. M, the initial x is a static binder, binding all free occurrences of x in M. As we have already met static binders in previous chapters, we omit the definitions of α-conversion, free variable, substitution, etc. We identify α-convertible terms, and therefore write M = N if M and N are α-convertible. A λ-term is closed if it contains no free variables. The set of free variables of a term M is written fv(M). The subset of A containing only the closed terms is Λ0.

To avoid too many brackets, we assume that application associates to the left, so that MNL should be read (MN)L, and that the scope of a A extends as far as possible to the right, so that λx.MN should be read λx. (MN). We also abbreviate λx1 …. λxn.M to λx1 … xn.M, or λx. M if the length of x is not important. We follow Barendregt [Bar84] and Hindlev and Seldin [HS86] in notations and terminology for the λ-calculus.

The basic computational step of the λ-calculus is β-reduction:

in which the placeholder x is replaced by the argument N in the body M of the function. An expression of the form (λx.M)N is called a β-redex, and the derivative is its contractum.

8.1 Linearity

The purpose of the type systems for linearity is to control the number of times a resource is used. In the specific case of the π-calculus the resources are the names.

The linear types for the π-calculus are a refinement of the i/o types that allow us to impose not only polarity, but also multiplicity constraints: we can say that a name should be used in input or in output only once. A linear type can take three forms: ℓo T, ℓi Tand ℓ# T. They are, respectively, the linear versions of the types o T, i T, and # T. A type ℓo T for a name gives the capability of transmitting a value of type T along that name once. Dually, ℓi T gives the capability of receiving a value of type T once. Finally ℓ# T is the type of a name that can be used once for transmitting and once for receiving a value of type T; type ℓ# T is the union of the capabilities offered by ℓi T and ℓo T. (By contrast with # T, the linear type ℓ# T does not give the right to test the identity of a name; a name that is used both for a communication and for a test is not linear, because it is used twice.) For instance, the processes

are well typed in {a : ℓo T, b : T, c : # ℓo T}. Note that the process ca does not itself exercise the output capability on a, but passes it to another process. By contrast, the same typing is not respected by the processes

We add linear types to a simplv-tvped π-calculus with i/o types; is the resulting calculus. Types, and related operations, are presented in Table 8.1. Moving from to all typing rules for processes and values, except that for restriction, that for matching, and that for subsumption, have to be modified.

We have seen in the General Introduction that the incarnations of mobility can be quite different. To a first approximation, however, we can distinguish two categories: models involving movement of computational entities, such as processes and parametrized processes, and models involving movement of communication links. Correspondingly, there are two main approaches to representing mobility in process calculi: the higher-order (or process-passing) paradigm, and the first- order (or name-passing) paradigm. The higher-order paradigm inherits from the λ-calculus the idea that a computation step involves instantiation of variables by terms.

The first-order paradigm is the mathematically simpler of the two. A fundamental point - without which the significance of the π-calculus would be strongly diminished - is that communication of names is enough to model communications involving processes. The formalization and validation of this claim is a central topic of this Part. The study has two main motivations. The first is expressiveness - two different paradigms are being compared. The second is semantics of higher-order languages: we wish to understand whether the π-calculus can be used as a metalanguage for describing and reasoning about such languages. Especially interesting is the possibility of using the theory of the π-calculus to derive proof techniques for higher-order languages. Obtaining proof techniques directly on these languages may be hard; see the discussion in the notes at the end of the Part. The basis for the study is laid down in this Part; the study is continued in Part VI, where we look at reduction strategies.

We begin Part V by introducing the Higher-Order π-calculus, HOπ, a higher- order extension of the core calculus Base-π of Section 6.2. In HOπ, parametrized processes, that is, abstractions, may be transmitted. An abstraction has a functional type. Applying an abstraction of type T → ⋄ to an argument of type T yields a process. The argument can itself be an abstraction; therefore the order of an abstraction, that is, the level of arrow nesting in its type, can be arbitrarily high.

12.1 Simply-typed HOπ

We extend Base-π and move to higher order by allowing values built out of processes. We use Higher-Order π-calculus, briefly HOπ, as a general name for a higher-order extension of Base-π.

Passing a process is like passing a parameterless procedure. The recipient of a process can do nothing with it but execute it, possibly several times. Procedures gain great utility if they can be parametrized so that, when invoked, some arguments may be supplied. In the same way a higher-order process calculus gains power if the processes that are communicated may be parametrized (see also the discussion at the end of Section 13.1.1). A parametrized process, an abstraction, is an expression of the form (x).P. We have already met abstractions in previous Parts of the book - Definition 2.4.38, Section 7.4.1; in this Part and the next, they play a central role. We may also regard abstractions as components of input-prefixed processes, viewing a(x).P as an abstraction located at a. Indeed, the part (x).P of a(x).P behaves exactly like an abstraction. In (x).P as in a(x).P, the displayed occurrence of x is binding with scope P.

When an abstraction (x).P is applied to an argument w it yields the process P{w/x}. Application is the destructor for abstractions. The application of an abstraction v to a value v’ is written, where T is the type of v'. (The type annotation is to ensure that the typing derivation of a process is unique, which will facilitate the encoding of HOπ into π-calculus. An alternative is to annotate the binding occurrences of names in abstractions, as is common in λ-calculi. Our choice keeps the syntax of abstraction closer to that of input.) At the level of types, adding parametrization means adding function types; thus in the value v has type T → ⋄, where ⋄ is the behaviour type (the type of processes, Section 6.1).

19.1 A programming language

A central issue in object-oriented programming is how objects are described. Broadly, object-oriented languages fall into two groups. One comprises the object-based languages, such as Emerald and Self. In a program of an object-based language, one finds phrases that express individual objects, and objects are created by performing operations on existing objects. The other, larger, group comprises the class-based languages. Among its members are Simula, Smalltalk, C++, and Java. A program of a class-based language contains definitions of classes, which serve as blueprints for objects that share a common structure and behaviour. The language we will consider is class-based. The ideas and techniques illustrated can also be applied to object-based languages, however.

A key idea in object-oriented design and programming is encapsulation: each object has private data that are not directly accessible to other objects. These are typically simple data, such as integers, and references to objects. An object a can interact with an object b only if a has a reference to b. An interaction typically consists in a asking b to carry out one of its repertoire of actions - that is, in a invoking one of b7s methods - and b returning the result of the invocation, in due course. The arguments and results of method invocations can contain references to objects, and it is in this way, and via creation of objects, that the interconnection structure among objects changes as a system evolves.

We call the language we consider OOL. Its main syntactic categories are declarations, commands, and expressions. A program comprises some class declarations and an expression, whose evaluation serves to trigger the system's activity. A class declaration consists of some variable declarations, the instance variables of the class, and some method declarations, which describe the actions that objects of the class can perform. A method declaration comprises type information and the body of the method, a command that describes the activity to be carried out when the method is invoked. A variable declaration states the names and types of variables.

In this Part we study the use of types for reasoning about behavioural properties of mobile processes.

Although well-developed, the theory of the pure untyped π-calculus is often insufficient to prove ‘expected’ properties of processes. The reason is that when one uses π-calculus to describe a system, one normally follows a discipline that governs how names may be used; but this discipline is not explicit in π-terms, and therefore it cannot play a part in proofs. (The same happens for the λ-calculus, which is hardly ever used untyped, since each variable usually has an ‘intended’ functionality.) Types can be used to make such disciplines explicit. In Section 9.1, we illustrate this point with two examples that have to do with encapsulation.

The use of types affects contextuallv-defined behavioural equivalences such as barbed congruence, for in a typed calculus the processes being compared must obey the same typing, and the contexts in which they are tested must be compatible with this typing. Typically, in a typed calculus the class of legal contexts in which two processes may be tested is smaller than in the untyped calculus. As a consequence, more behavioural equivalences among processes hold. The behavioural effects of types are important for types such as i/o, linear, receptive, and polymorphic types, because such types express behavioural guarantees on the use of names. Types are important not only for behavioural equivalences, but more generally for behavioural properties; see for instance the security property discussed in Section 9.3.

Basic definitions, such as those of typed barbed congruence and typed labelled equivalences, will be parametric on the type system. However, most results will be presented on concrete π-calculi, usually extensions of π, the polvadic π-calculus. π is simple (for instance it has no basic types), it is an adequate testbed for the results, and it is a common core calculus in applications. The equivalences we present are also valid in other type systems, as long as the key conditions on the usage of names (such as i/o capabilities and receptiveness) are respected. We will point out when this is not the case. In examples we will often use also integer and boolean values.

6.1 Terminology and notation for typed calculi

We introduce some terminology and notation for describing typed calculi. On a first reading, it may be best to skim over this section. The main reason for collecting the material here is to make it easier for the reader to find where certain terminology and notation is introduced, than it would be if it were scattered throughout the text.

Definition 6.1.1 (Type environment) An assignment of a type to a name is of the form a : T, where a is a name, called the name of the assignment, and T is a type, called the type of the assignment.

A type environment (or type assumption, or, briefly, typing) is a finite set of assignments of types to names, where the names in the assignments are all different.

We use Γ, Δ to range over type environments. We ignore the order of the assignments in a type environment. We sometimes regard a type environment Γ as a finite function from names to types. Therefore we write Γ(a) for the type assigned to a by Γ, and say that the names of the assignments in Γ are the names on which Γ is defined. For now, we also call the names of the assignments in Γ the support of Γ, written supp(Γ). When we consider polymorphism, however, a type environment Γ will also include a set of type variables, and supp(Γ) will also include these variables.

To facilitate reading, we sometimes omit curly brackets outside a type environment. For instance we write a : T, b : S for the type environment that assigns T to a, S to b and is undefined on the other names. We write Γ, Δ for the type environment that is the union of Γ and Δ; often Δ consists of a single type assignment, as in Γ, a : T. Whenever we extend a type environment, we implicitly assume that the environment was not defined on the added names.

17.1 The full-abstraction problem for the π-interpretation of call-by-name

An interpretation of the λ-calculus into π-calculus, as a translation of one language into another, can be considered a form of denotational semantics. The denotation of a λ-term is an equivalence class of processes. These equivalence classes are the quotient of the π-calculus processes with respect to barbed congruence, the behavioural equivalence of the π-calculus.

In the two previous chapters, we have seen various π-calculus interpretations of λ-calculi and have shown their soundness with respect to the axiomatic semantics of the calculi, where equivalence between λ-terms means provable equality from an appropriate set of axioms and inference rules. In this chapter and the next, we go further and compare the π-calculus semantics with the operational semantics of the λ-calculus. We study the important case of the untyped call-by-name λ-calculus (λN); the problem is harder in the call-by-value case, and is briefly discussed in Section 18.5. The encoding of λN into π-calculus will be that of Table 15.4, but without i/o types. We can assume that the encoding is into the plain polvadic π-calculus (π), without i/o types, because Lemma 15.4.18 shows that i/o types do not affect behavioural equivalence; in Lemma 15.4.18 we indicated the encoding without i/o types as N#.

An interpretation of a calculus is said to be sound if it equates only operationally equivalent terms, complete if it equates all operationally equivalent terms, and fully abstract if it is sound and complete. We show in Section 17.3 that the π-calculus interpretation of λN is sound, but not complete.

When an interpretation of a calculus is not fully abstract, one may hope to achieve full abstraction by

• (1) enriching the calculus,

• (2) choosing a finer notion of operational equivalence for the calculus, or

• (3) cutting down the codomain of the interpretation.

In Section 17.4 and Chapter 18 we prove full-abstraction results for the π-interpretation by following (1) and (2), respectively. In the notes at the end of the Part, we will hint that the main theorems are, by and large, independent of the behavioural equivalence chosen for the π-calculus, which suggests that (3) is less interesting.

Mobile systems, whose components communicate and change their structure, now pervade the informational world and the wider world of which it is a part. But the science of mobile systems is yet immature. This science must be developed if we are properly to understand mobile systems, and if we are to design systems so that they do what they are intended to do. This book presents the π-calculus, a theory of mobile systems, and shows how to use it to express systems precisely and reason about their behaviour rigorously.

The book is intended to serve both as a reference for the theory and as an extended demonstration of how to use the π-calculus to express systems and analyse their properties. The book therefore presents the theory in detail, with emphasis on proof techniques. How to use the techniques is shown both in proofs of results that form part of the theory and in example applications of it.

The book is in seven Parts. Part I introduces the π-calculus and develops its basic theory. Part II presents variations of the basic theory and important subcalculi of the π-calculus. A distinctive feature of the calculus is its rich theory of types for mobile systems. Part III introduces this theory, and Part IV shows how it is useful for understanding and reasoning about systems. Part V examines the relationship between the π-calculus and higher-order process calculi. Part VI analyses the relationship between the π-calculus and the λ-calculus. Part VII shows how ideas from π-calculus can be useful in object-oriented design and programming.

The book is written at the graduate level and is intended for computer scientists interested in mobile systems. It assumes no prior acquaintance with the π-calculus: both the theory and the viewpoint that underlies it are explained from the beginning.

Although the book covers quite a lot of ground, several topics, notably logics for mobility, and denotational and non-interleaving semantics, are not treated at all. The book contains detailed accounts of a selection of topics, chosen for their interest and because they allow us to explore concepts and techniques that can also be used elsewhere. Each Part ends with some references to sources and additional notes on related topics.

In this chapter we show that the encodings of the previous chapter can be extended to encodings of typed λ-calculi. To do this we have to define translations on types to match those on terms. We analyse the case of the simply-typed λ-calculus in detail, and discuss subtyping and recursive types. For studies of other type systems, see the notes at the end of the Part.

16.1 Typed λ-calculus

In a core simplv-typed λ-calculus, types are built from basic types, such as integers and booleans, using the function type constructor. The syntax of terms is that of the untyped λ-calculus plus basic constants. Each constant has a unique predefined type. We use only constants of basic types: this is sufficient to have a non-empty set of (closed) well-typed terms. This simplv-typed λ-calculus is presented in Table 16.1. We write Λ{c} for the set of terms of the calculus. As usual, function type associates to the right, so T → S → U should be read T → (S → U). Basic types are ranged over by t, basic constants by c. The reduction relation and the reduction strategies are defined as for the untyped calculus; the only difference is that the set of values for a reduction strategy normally contains the constants. We call the typed versions of λV and λN simply-typed call-by-value (λV→) and simply-typed call-by-name (λN→), respectively.

We add the same basic constants and basic types to HOπ and π-calculus and repeat the diagram of Figure 15.1, this time for λV→ and λN→. We show how to extend the encodings of λV and λN (from Sections 15.3 and 15.4), and their correctness results, to take account of types. The encodings in Sections 15.5-15.7 can be extended similarly.

Lemma 16.1.1 In the simplv-typed λ-calculus, for every Γ and M there is at most one T such that Γ M : T .

16.2 The interpretation of typed call-by-value

We begin with the left part of Figure 15.1, which concerns λV We follow a schema similar to that of Section 15.3, pointing out the main additions.