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.

5.1 The Asynchronous π-calculus

The π-calculus takes over from CCS a kind of synchronized communication, in which an interaction involves the joint participation of two processes. The prefix operator expresses temporal precedence: the sole capability of xy. P is to send via x, and that of x(z). Q to receive via x, and in each case it is only after the relevant capability has been exercised that the behaviour expressed by the term underneath the prefix can unfold. The combination of prefixing and synchronized communication is versatile and tractable.

On the other hand, some concurrent systems, especially distributed systems, use forms of asynchronous communication, in which the act of sending a datum and the act of receiving it are separate. Often, such communication involves an explicit medium of some kind, and sending and receiving data involve putting them into and taking them out of the medium. Media exhibit a variety of characteristics. For instance, they may have bounded or unbounded capacity, and they may or may not preserve some ordering among the data they contain. There may be an arbitrary delay between a datum being sent and it being received. If the communication medium has unbounded capacity, no process need wait to send a datum.

This section and the following four are about a subcalculus of the π-calculus in which communication can be understood as asynchronous. The key step in achieving this is the decree that, in the subcalculus, the only term that can appear underneath an output prefix is 0. Thus, the only output-prefixed terms are of the shape xy. 0, or, in abbreviated form, xy. In a term of the subcalculus, an unguarded occurrence of a particle xy can be thought of as a datum y in an implicit communication medium, tagged with x to indicate that it is available to any unguarded subterm of the form x(z).P. Thus, in the evolution of a term, the datum y can be considered to be sent when xy becomes unguarded, and to be received when xy disappears via an intraaction of the form

This reduction has two effects: the particle xy is consumed and removed from the communication medium; and the unguarded output particles in P{y/z} are liberated and put into the medium.

1.1 Syntax

This section introduces the language of the π-calculus. Its terms, the processes, express mobile systems.

The meanings of processes are discussed informally, and name-binding and name-substitution, two notions needed for the formal account, are explained.

The simplest entities of the π-calculus are names. They can be thought of as names of communication links. Processes use names to interact, and pass names to one another by mentioning them in interactions. Names received by a process can be used and mentioned by it in further interactions. A countablv-infinite set of names is presupposed, ranged over by lower-case letters.

Processes evolve by performing actions. The capabilities for action are expressed via the prefixes, of which there are four kinds:

The first capability is to send the name y via the name x, and the second to receive any name via x - the role of z will be explained shortly. The third is a capability for unobservable action - this will also be explained soon. The fourth is a conditional capability: the capability π if x and y are the same name.

We now define the processes and a particular subclass of them.

Definition 1.1.1 (π-calculus) The processes and the summations of the π- calculus are given respectively by

We give a brief, informal account of the intended interpretation of processes, beginning with the summations.

• (1) 0 is inaction; it is a process that can do nothing.

• (2) The prefix it. P has a single capability, expressed by π; the process P cannot proceed until that capability has been exercised.

• The output prefix xy. P can send the name y via the name x and continue as P.

• The input prefix x(z).P can receive any name via x and continue as P with the received name substituted for z.