This page intentionally left blank

A DISTRIBUTED pi-calculus

Distributed systems are fast becoming the norm in computer science. Formal
mathematical models and theories of distributed behaviour are needed in order to
understand them. This book proposes a distributed pi-calculus called aDpi, for
describing the behaviour of mobile agents in a distributed world. It is based on an
existing formal language, the pi-calculus, to which it adds a network layer and a
primitive migration construct.
A mathematical theory of the behaviour of these distributed systems is developed,
in which the presence of types plays a major role. It is also shown how, in principle,
this theory can be used to develop verification techniques for guaranteeing the
behaviour of distributed agents.
The text is accessible to computer scientists with a minimal background in
discrete mathematics. It contains an elementary account of the pi-calculus, and
the associated theory of bisimulations. It also develops the type theory required by
aDpi from first principles.
A DISTRIBUTED pi-calculus

M ATT H E W HE NNE SSY

CAMBRIDGE UNIVERSITY PRESS
Cambridge, New York, Melbourne, Madrid, Cape Town, Singapore, São Paulo

Cambridge University Press

The Edinburgh Building, Cambridge CB2 8RU, UK
Published in the United States of America by Cambridge University Press, New York
www.cambridge.org
Information on this title: www.cambridge.org/9780521873307

© Cambridge University Press, 2007

This publication is in copyright. Subject to statutory exception and to the provision of

relevant collective licensing agreements, no reproduction of any part may take place
without the written permission of Cambridge University Press.

First published in print format 2007

ISBN-13 978-0-511-27564-7 eBook (NetLibrary)

ISBN-10 0-511-27564-1 eBook (NetLibrary)

ISBN-13 978-0-521-87330-7 hardback

ISBN-10 0-521-87330-4 hardback

Cambridge University Press has no responsibility for the persistence or accuracy of urls
for external or third-party internet websites referred to in this publication, and does not
guarantee that any content on such websites is, or will remain, accurate or appropriate.
To the memory of John and Ray
 Contents

Preface ix
Acknowledgements xvii

1 Inductive principles 1
1.1 Induction 1
1.2 Coinduction 4
1.3 Bisimulation equivalence 6

2 The asynchronous PI-CALCULUS 10

2.1 The language aPi 10
2.2 Reduction semantics for aPi 16
2.3 An action semantics for aPi 27
2.4 A coinductive behavioural equivalence for aPi 34
2.5 Contextual equivalences 37
2.6 An observational lts for aPi 43
2.7 Justifying bisimulation equivalence contextually 47
2.8 Questions 52

3 Types for API 55

3.1 Runtime errors 55
3.2 Typechecking with simple types 60
3.3 Properties of typechecking 65
3.4 Types as capabilities 72
3.5 Questions 93

4 Types and behaviour in aPi 96

4.1 Actions-in-context for aPi 98
4.2 Typed bisimulation equivalence 112
4.3 Questions 122
vii
viii Contents

5 A distributed asynchronous PI-CALCULUS 124

5.1 The language aDpi 127
5.2 Access control types for aDpi 139
5.3 Subject reduction for aDpi 159
5.4 Type safety for aDpi 169
5.5 Distributed consistency of local channels 185
5.6 Questions 191

6 Behavioural equivalences for aDpi 194

6.1 Actions-in-context for aDpi 195
6.2 Typed bisimulation equivalence for aDpi 200
6.3 Describing bisimulations 202
6.4 Servers and clients 215
6.5 Modelling a firewall 221
6.6 Typed contextual equivalences 226
6.7 Justifying bisimulation equivalence contextually in aDpi 230
6.8 Questions 242

Sources 244
List of figures 248
Notation 250
Bibliography 254
Index 257
 Preface

From ATM machines dispensing cash from our bank accounts, to online
shopping websites, interactive systems permeate our everyday life. The underlying
technology to support these systems, both hardware and software, is well advanced.
However design principles and techniques for assuring their correct behaviour are
at a much more primitive stage.
The provision of solid foundations for such activities, mathematical models
of system behaviour and associated reasoning tools, has been a central theme of
theoretical computer science over the last two decades. One approach has been the
design of formal calculi in which the fundamental concepts underlying interactive
systems can be described, and studied. The most obvious analogy is the use of the
λ-calculus as a simple model for the study of sequential computation, or indeed the
study of sequential programming languages. CCS (a Calculus for Communicating
Systems) [28] was perhaps the first calculus proposed for the study of interactive
systems, and was followed by numerous variations. This calculus consists of:

• A simple formal language for describing systems in terms of their structure; how they are
constructed from individual, but interconnected, components.
• A semantic theory that seeks to understand the behaviour of systems described in the
language, in terms of their ability to interact with users.

Here a system consists of a finite number of independent processes that inter-

communicate using a fixed set of named communication channels. This set of
channels constitutes a connection topology through which all communication takes
place; it includes both communication between system components, and between
the system and its users.
Although successful, CCS can only describe a very limited range of systems. The
most serious restriction is that for any particular system its connection topology
is static. However modern interactive systems are highly dynamic, particularly
when one considers the proliferation of wide area networks. Here computational

ix
x Preface

entities, or agents, are highly mobile, and as they roam the underlying network they
forge new communication links with other entities, and perhaps relinquish existing
links.
The pi-calculus [9, 29] is a development from CCS that seeks to address at
least some dynamic aspects of such agents. Specifically it includes the dynamic
generation of communication channels and thus allows the underlying connection
topology to vary as systems evolve. Just as importantly it allows private
communication links to be established and maintained between agents, which adds
considerably to its expressive power. Indeed the pi-calculus very quickly became
the focus of intensive research, both in providing for it a semantic understanding,
and in its promotion as a suitable foundation for a theory of distributed systems;
see [39] for a comprehensive account.
But many concepts fundamental to modern distributed systems, in particular
those based on local area networks, are at most implicit in the pi-calculus. Perhaps
the most obvious is that of domain, to be understood quite generally as a locus for
computational activity. Thus one could view a distributed system as consisting of
a collection of domains, each capable of hosting computational processes, which
in turn can migrate between domains.
The aim of this book is to develop an extension of the pi-calculus in which
these domains have an explicit representation. Of course when presented with such
a prospect there is a bewildering number of concerns on which we may wish to
focus. For example:

• What is the role of these domains?

• How are they to be structured?
• How is interprocess communication to be handled?
• How is agent migration to be described?
• Can agents be trusted upon entry to a domain?

Indeed the list is endless. Here our approach is conservative. We wish to develop
a minimal extension of the pi-calculus in which the concept of domain plays a
meaningful, and non-trivial role. However their presence automatically brings a
change of focus. The set of communication channels that in the pi-calculus
determines the interprocess communication topology now has to be reconciled with
the distribution topology. Following our minimalistic approach we decide on a very
simple distribution topology, namely a set of independent and non-overlapping
domains, and only allow communication to happen within individual domains.
This makes the communication channels of the pi-calculus into local entities, in
the sense that they only have significance relative to a particular domain. Indeed
we will view them as a particularly simple form of local resource, to be used by
 Preface xi

migrant agents. Thus we view our extension of the pi-calculus, called aDpi – for
asynchronous Distributed pi-calculus, as a calculus for distributed systems in
which
• dynamically created domains are hosts to resources, which may be used by agents
• agents reside in domains, and may migrate between domains for the purpose of using
locally defined resources.

Types and type inference systems now form an intrinsic part of computer science.
They are traditionally used in programming languages as a form of static analysis
to ensure that no runtime errors occur during program execution. Increasingly
sophisticated type-theoretic concepts have emerged in order to handle modern
programming constructs [36]. However the application of type theory is very
diverse. For example types can be used to
• check the correctness of security protocols [12]
• detect deadlocks and livelocks in concurrent programs [26]
• analyse information flow in security systems [22].

In this book we also demonstrate how type systems can be developed to manage
access control to resources in distributed systems. In aDpi we can view domains
as offering resources, modelled as communication channels, to migrating agents.
Moreover a domain may wish to restrict access to certain resources to selected
agents. More generally we can think of resources having capabilities associated
with them. In our case two natural capabilities spring to mind:
• the ability to update a resource, that is write to a communication channel
• the ability to look up a resource, that is read from a communication channel.

Then domains may wish to distribute selectively to agents such capabilities on its
local resources.
We could develop a version of aDpi in which the principal values manipulated by
agents are these capabilities. But this would be a rather complex language, having
to explicitly track their generation, management, and distribution. Instead we show
that these capabilities can be implicitly managed by using a typed version of aDpi.
Moreover the required types are only a mild generalisation of those used in a type
inference system for ensuring the absence of runtime errors, when aDpi systems
are considered as distributed programs.
The behavioural theory of processes originally developed for CCS [28] based on
bisimulations, has been extended to the pi-calculus, and can be readily extended
to aDpi. Indeed the framework is quite general. The behaviour of processes can
be described, independently of the syntax, in terms of their ability to interact with
other processes, or more generally with their computing environment. The form
xii Preface

these interactions take depend on the nature of the processes, and in general will
depend on the process description language. They can be described mathematically
as relations between processes, with
l
P −→ Q

meaning the process P by interacting with its environment can be transformed into
the process Q. The label l serves to record the kind of interaction involved, and
perhaps some data used in the interaction. For example one can easily imagine the
behaviour of an ATM machine being described in this manner, in terms of its internal
states, and the evolution between these states depending of the different kinds of
interactions with a customer. Such a behavioural description is formalised as a
labelled transition system, or lts, and often refered to as an operational semantics.
The theory of bisimulations enables one to take such abstract behavioural
descriptions of processes and generate a behavioural equivalence between
processes. Intuitively
P≈Q (1)
will mean that no user, or computing environment, will be able to distinguish
between P and Q using the interactions described in their behavioural descriptions.
However the use of types in aDpi has a serious impact on this general behavioural
framework, particularly as these types implicitly represent the limited capabilities
that agents have over resources. In other words these types limit the ways in which
agents can interact with other agents. Consequently whether or not two agents are
deemed equivalent will depend on the current distribution of the capabilities on the
resources in the system.
The third and final aim of this book is to address this issue. We demonstrate
that the general theory of bisimulations can be adapted to take the presence of
types into account. We develop a relativised version of behavioural equivalence in
which judgements such as (1) can never be made in absolute terms, but relative to a
description of current capabilities. Moreover we will show that the proof techniques
associated with standard bisimulations, based on coinduction, can be adapted to this
more general framework, at least in principle.
A secondary aim of the book is didactic. Research into the use of formal calculi
to model distributed or interactive systems, or even understanding the application
of such calculi, requires detailed knowledge of a variety of mathematical concepts.
We hope that the book will provide a good introduction to a range of these concepts,
and equip the reader with sufficient understanding and familiarity to enable them
to pursue independent research in the area. But we do not start from first principles.
We assume the reader is at least familiar with elementary discrete mathematics,
 Preface xiii

and in particular structural induction. It would also be helpful to have a passing

acquaintance with bisimulations, as in [28]. Chapter 1 reviews the knowledge
assumed in these areas. But other than this, the aim is to be self-contained. In
particular we give a detailed exposition of the pi-calculus, and an elementary
introduction to types and typing systems.

Structure
As already stated, Chapter 1: Background recalls elementary notions of induction
and coinduction, which will be used extensively in all subsequent chapters.
However the only form of coinduction to be used is that associated with
bisimulations, the theory of which is also reviewed.
The pi-calculus, or at least our version of it – called aPi, for asynchronous
pi-calculus, is explained in Chapter 2: The asynchronous PI-CALCULUS. This
exposition starts from first principles, giving a detailed account of both syntactic and
semantic concerns. We give two semantic accounts. The first, a so-called reduction
semantics, may be viewed as a description, at a suitable level of abstraction, of a
prototypical implementation of the language, explaining how aPi processes can be
executed. The second gives an lts for aPi, explaining how processes can interact,
by communicating along channels, with their peers. As we have already indicated
this automatically gives us a bisimulation equivalence between processes, and
moreover bisimulation theory supplies a very powerful coinductive proof principle
for establishing equivalences.
However perhaps the most important topic in this chapter is a discussion of
appropriate behavioural equivalences for process description languages in general.
On the basis of some simple criteria we give a definition of a behavioural
equivalence between processes, called reduction barbed congruence, =, ∼ which
has the advantage of being applicable, or at least easily adapted to, most process
description languages. We will also argue that it is the most natural semantic
equivalence between processes; it relies essentially only on the process description
language having a reduction semantics, and therefore is widely applicable. The
chapter ends by showing how bisimulation equivalence needs to be adapted so as
to coincide with =,∼ thereby providing a complete coinductive proof principle for
this natural behavioural equivalence.
In Chapter 3: Types in API we turn our attention to types, using a typed version
of our language, typed aPi. By focusing on a straightforward notion of runtime
error for aPi, we first explain the use of type systems, the general structure that the
types need to take and the associated typechecking system. We then elaborate on
xiv Preface

the kind of technical results one needs to establish about such a framework. These
cumulate to the demonstration of:
• Subject reduction: the property of being well-typed is preserved under the reduction
semantics.
• Type safety: well-typed processes do not give rise to runtime errors.

Next we introduce a more sophisticated capability-based type system, in which

a type corresponds to a set of capabilities, or permissions, on a channel or resource.
By means of examples we show how this type system can be used to manage, or
control, access to these resources. Establishing the required technical results in this
case is somewhat more challenging.
As we have already indicated, the presence of types affects the perceived
behaviour of processes, and consequently the behavioural theories of Chapter 2
need to be adapted to typed aPi. This is the topic of Chapter 4: Types and
behaviour in aPi , and is quite a challenge. We need to adapt the standard approach
for producing an lts from a process description language, explained in detailed in
Chapter 2, to generate a more descriptive lts in which the actions are parameterised
by the environment’s knowledge of the current capabilities concerned. Most of this
chapter is concerned with technical results, which ensure that the resulting lts is, in
some sense, self-consistent.
We then go on to show how this parameterised lts can be used to generate
a parameterised version of bisimulation equivalence between processes. In fact
this is relatively straightforward, but we also need to prove that the resulting
parameterised equivalence satisfies a range of mathematical properties, which one
would intuitively expect from such a framework.
At last, in Chapter 5: A distributed asynchronous pi-calculus we give a
detailed account of our distributed version of aPi, called aDpi. The syntax is
obtained by adding a new syntactic category, for systems, to that of typed aPi. We
obtain a description language in which systems consist of a collection of domains,
hosting agents, which can autonomously migrate between domains. These domains
also host local channels on which agents communicate; but more generally these
may be used to model local resources, accessible to agents currently located at the
host domain. The capability-based type system from Chapter 3 is also extended.
One novelty is the use of record types for domains, but the fact that resources are
purely local also requires a significant extension to the set of types. Essentially
the name of a local resource is useless, without knowledge of its location; for this
reason local resources are typed using a primitive kind of existential channel type.
We demonstrate the usefulness of the typing system via a sequence of examples,
and of course we also prove that it satisfies the standard properties one would
expect of any reasonable typing system. The chapter then ends with a detailed
 Preface xv

Chapter 1: Background

Chapter 2: API

Chapter 3: Types for API

Chapter 4: Types and behaviour in API Chapter 5: ADPI

Chapter 6: Behavioural equivalences for ADPI

formal account of the role of types in aDpi. This involves defining a version
of aDpi, called tagged-aDpi, in which capabilities, rather than values, are the
main entities manipulated by agents. This is a rather complicated language as the
capabilities, and their propagation, have to be explicitly managed by the reduction
semantics. However we demonstrate that in reality, there is no need for such a
detailed language; in the presence of the capability-based type system aDpi can
be considered as a more abstract, and therefore more manageable, version of
tagged-aDpi.
In Chapter 6: Behavioural equivalences for ADPI we adapt the parameterised
theory of bisimulation equivalence from Chapter 4 to aDpi. In fact we spare the
reader most of the technical proofs, as they can easily be adapted from those for
aPi. Instead we show, via a number of examples, that at least in theory many of the
standard methodologies associated with bisimulation equivalence can be adapted
to prove equivalences between aDpi systems.
We also revisit the principal topic of Chapter 2. We justify our parameterised
version of bisimulation equivalence by showing that it coincides with a natural
intuitively defined behavioural equivalence, a typed version of reduction barbed
congruence.
xvi Preface

We end with a brief section, entitled Sources, with references to the original
research papers on which our material is based, together with some pointers to
related work.
The book is essentially divided into two parts. After reviewing some required
background material in Chapter 2, the following three chapters aim to give a
coherent and detailed introduction to the pi-calculus. These chapters could form
the basis of a postgraduate course on the pi-calculus. Although they pursue
a particular viewpoint, students completing them should be competent in the
mathematical techniques underlying the theory of the pi-calculus, and therefore
should have no problem absorbing supplementary material, taken for example from
[39], [29], or the research literature.
The second part of the book, Chapter 5 and Chapter 6, give a detailed account
of the language aDpi, and its behavioural theory. This could form the core of a
postgraduate course on process calculi for distributed systems, for students familiar
with the pi-calculus. However once more this would need to be augmented with
additional material from the research literature, to reflect the varied approaches to
the subject.
Alternatively, a less theoretical course could be based upon the first four sections
of Chapter 2, Chapter 3 and the first three sections of Chapter 5. This foregoes most
of the material on behavioural equivalences, concentrating on the basic semantics
of the languages (the reduction semantics), and typing.
Each chapter ends with a set of exercises, which the reader is encouraged to
answer. For the most part these are related directly to the material of the chapter,
perhaps extending it in certain directions, or illustrating certain consequences. By
and large they should present no difficulties, although a few may be non-trivial.
 Acknowledgements

Most of the research reported on here was carried out over the years with a
large number of colleagues. The main language of the book, aDpi, was originally
developed in conjunction with James Riely, while the behavioural theory, in
Chapter 4 and Chapter 6, was developed jointly with Julian Rathke. Other
colleagues whose contributions and collaborative efforts I wish to acknowledge
include Alberto Ciaffaglione, Adrian Francalanza, Samuel Hym, Massimo Merro
and Nobuko Yoshida.
The book was largely written while the author held a Royal Society/Leverhulme
Trust Senior Fellowship during the academic year 2005/2006, although some
preliminary material on which it was based was presented at the Bertinoro
International Spring School for Graduate Studies in Computer Science in March
2004.
Finally a number of colleagues read parts of the book in draft form, and made
numerous useful suggestions for improvements. These include Adrian Francalanza,
Samuel Hym, Sergio Maffeis, Julian Rathke, James Riely and Nobuko Yoshida.

xvii
 1
Inductive principles

Throughout the book we will make extensive use of both induction and coinduction,
and their associated proof techniques. Here we give a brief review of these concepts,
and an indication of how we intend to use them.

1.1 Induction
Figure 1.1 contains a definition of the (abstract) syntax of a simple language of
machines. Here a ranges over some set of action labels Act, and intuitively a
machine can carry out sequences of these actions, and periodically has a choice of
which actions to perform. Let M be the set of all machines defined in Figure 1.1.
Formally this is an inductive definition of a set, namely the least set S that satisfies
• stop ∈ S
• M ∈ S implies a.M ∈ S for every action label a in Act
• M1 , M2 ∈ S implies M1 + M2 ∈ S.

The fact that M is the least set that satisfies these conditions gives us a proof
technique for defining and proving properties of machines in M; any other set
satisfying the conditions is guaranteed to contain M.
As an example consider the following definition of the size of a machine:
• | stop | = 0
• |a.M | = 1 + |M |
• |M1 + M2 | = |M1 | + |M2 |.

We know by induction that this function is now defined for every machine.
Belabouring the point for emphasis let D be the domain of the size function | |,
the set of elements for which it is defined. The three clauses in the definition of
| | above imply that D satisfies the three defining properties of M. So we can
conclude that M ⊆ D; that is every machine is in the domain of | |. We refer to

1
2 Inductive principles

Figure 1.1 Syntax for finite machines

this form of induction as structural induction, as it uses the structure of the language
of machines.
We can also use induction to define the intended behaviour of machines. These
machines perform sequences of actions, but these sequences can be characterised
indirectly by describing what initial action a machine M can perform, and the
residual of M after the action, the part of M that subsequently remains to be
executed. This is given by defining a ternary relation over M × Act × M, with
a
M −→ N (1.1)
indicating that the machine M can perform an action labelled a, with N as residual.
a
Formally the relation M −→ N is defined inductively, as the least relation that
satisfies the axiom (m-move), and the rules (m-choice.l) and (m-choice.r) in
Figure 1.2. The general form of these rules is
(m-rule)
premise1 , . . . premisen
conclusion
This consists of a number, possibly zero, of premises, and a conclusion, meaning
that if all of the premises can be established then the conclusion is true. When the
set of premises is empty, we have an axiom, which will be written more simply as
(m-axiom)
conclusion
The nature of these rules ensures that there is always a least relation satisfying
them. Informally each rule can be viewed as a property of relations; it is true of R
if, whenever each premise is true of R it follows that the conclusion is also true
of R. Now consider a collection of such rules, C . Suppose Ri , i ∈ I , is a family
of relations, all of which satisfy each rule in C . Then one can check that ∩I Ri also
satisfies them. So the least relation satisfying the rules C can be taken to be the
intersection of all the relations satisfying them. In fact we take this least relation to
be the relation defined by the rules C .

Figure 1.2 An inductive definition of actions

 1.1 Induction 3

More prosaically one can show this least relation simply consists of all
judgements for which there is a proof using the rules from C . As an example of such
a C take those in Figure 1.2, consisting of one axiom and two rules. We can take
(1.1) above to be the relation defined by C . Thus if we assert (1.1) for a particular
M , N and a, then we have a proof of this fact, using a series of applications of this
axiom and of the two rules. For example we can prove
a
a.(b. stop + a. stop) + b.(a. stop + c.b. stop) −→ (b. stop + a. stop) (1.2)
in two steps. The first is an application of the axiom (m-move) to obtain
a
a.(b. stop + a. stop) −→ (b. stop + a. stop)
Then an application of (m-choice.l) to this gives (1.2).
So if we want to prove a property of any judgement of the form (1.1) above we
can use induction on the length of its proof; that is on the number of applications of
rules or axioms, or more generally on the structure of the proof. We call this form
of induction rule induction.
As an example of its use let us prove the following, rather obvious, fact:
Lemma 1.1 If M −
→a
M  then |M  | < |M |.
Proof: There is an embarrassing number of inductive definitions involved in this
statement; the set of machines over which M and M  range, the inductively defined
a
function | | and the inductively defined relation M −→ N ; for the purposes of
exposition we concentrate on this last.
Since M −→ a
M  we have a proof of this fact using the rules in Figure 1.2. We
prove the statement of the lemma using induction on the structure of this proof;
that is we use rule induction.
The proof must have non-zero length, and we examine the last rule used in its
derivation. There are three possibilities.
• The first is when this last rule is (m-move), in which case the length of the proof is one.
Then M and M  are of the form a.N and N respectively, for some machine N . Looking up
the definition of the function | | we immediately find that |a.N | = 1 + |N |, and therefore
the required result is true.
• The second possibility is that the rule (m-choice.l) is used. So M has the form M1 + M2
and we know that M1 −→ a
M  . Moreover the derivation of this latter judgement is strictly
contained in that of M −→ M  . Therefore we may apply the inductive hypothesis to
a

conclude that |M  | < |M1 |. Again looking up the definition of the function we see that
|M | = |M1 | + |M2 |, and therefore |M1 | ≤ |M |. The requirement, that |M  | < |M |,
therefore again follows.
• The third and final possibility is that (m-choice.r) is the last rule used. This is another
inductive case, and the argument is identical to the second possibility.

4 Inductive principles
Let us end this section by remarking that formally we have defined (1.1) as a
ternary relation over M × Act × M. However we will often view this as a family
a
of relations −→, one for each a in Act.

1.2 Coinduction
Induction is a mathematical argument obtained by virtue of the fact that some
relation R is defined to be the least one satisfying certain properties; any other
relation satisfying these properties contains R. Coinduction, the dual argument,
is obtained by virtue of the fact that a relation R is defined to be the largest
one satisfying certain properties; then any other relation satisfying the defining
properties is contained in R. To see an example let us first set up the general
framework we will use in our behavioural descriptions of languages.
Definition 1.2 (lts) A labelled transition system, or more briefly, an lts, consists of
• a set of configurations or states, S
• a set of action labels, Act
• for each action label a, a binary next state relation Ra ⊆ S × S.
a
We will often use suggestive notation such as P −→ Q to denote the fact that P, Q

is contained in Ra , and refer to Q as a residual of P after performing the action a.



The set of states S will often be simply the set of terms of some language and the
relations will define the various ways in which observers or users can interact with
programs or processes written in the language. Figures 1.1 and 1.2 give a typical
example. Taken together they define the following lts:
• The set of states are all terms M that can be defined using the rules in Figure 1.1.
• For each action label a in Act the relation Ra consists of all pairs M , M 
for which the
a
judgement M −→ M  can be derived using the rules in Figure 1.2.

Indeed this is a proto-typical example of the operational semantics of a language.

We will see many other examples, but each follow precisely this schema. An lts will
be defined using the terms of some language for describing processes, some set of
action labels Act appropriate to the language, and for each a in Act an inductively
defined relation over process terms. Note that this framework will give us two
forms of induction; structural induction on process terms, and rule induction on
the relations.
a
Now consider an arbitrary lts, (S , Act, −→) and let R be an arbitrary relation over
the set of states S ; that is suppose R ⊆ S × S . We say R is a strong bisimulation
if it satisfies the following two properties:
a
(1) P1 R P2 and P1 −→ P1 implies P2 −→
a
P2 for some state P2 such that P1 R P2
(2) P1 R P2 and P2 −→ P2 implies P1 −→ P1 for some state P1 such that P1 R P2
a  a
 1.2 Coinduction 5

for every action a in Act. These properties are often written graphically (less
precisely); for example the property (1) of R above can be represented as:

This is often called the strong transfer property for R in the lts in question; in
these diagrams the dotted arrow refers to a relation that is required, as opposed
to the standard arrow that indicates a given relation. Note that property (2)
is equivalent to requiring that the inverse of R, denoted R−1 , also satisfies this
transfer property. In other words R is a bisimulation if it, and its inverse, satisfies
the transfer property. In general there is no requirement for a bisimulation to be
symmetric; but if it happens to be symmetric then checking (2), the transfer property
for its inverse, is vacuous.
We use ∼bis to denote the largest bisimulation, which is referred to as strong
bisimulation equivalence. Note that if Ri is any family of bisimulations, where
i ranges over some index set I , then it is easy to check that ∪I Ri is also a
bisimulation. From this we see that ∼bis exists since we can define it to be the
set theoretic union of all bisimulations.
The fact that ∼bis is the largest relation satisfying the transfer property gives us
a proof technique: any other relation satisfying the transfer property is contained
in ∼bis . So, for example, to prove that P ∼bis Q for some particular pair of states
P, Q, it is sufficient to exhibit any bisimulation containing the pair P, Q
. For
example
a.(b. stop + b. stop) + a.b. stop ∼bis a.b. stop
because the following is a bisimulation:
a.(b. stop + b. stop) + a.b. stop ↔ a.b. stop
b. stop + b. stop ↔ b. stop
b. stop ↔ b. stop
stop ↔ stop
Here we have given a graphical representation of a relation R over machine states
by enumerating all its elements; P ↔ Q signifies that the pair P, Q
is in R.
Demonstrating that R is indeed a bisimulation requires some checking. But an
exhaustive analysis will show that this relation does indeed satisfy the transfer
6 Inductive principles

property; each action by a process in the relation can be appropriately matched by

an action of its partner.
This form of reasoning, based on the fact that ∼bis is the largest relation satisfying
the strong transfer property, is an instance of coinduction. We will use it frequently,
both to show particular processes equivalent, but also to prove more general
properties. As a simple example of the latter let us prove:
a
Lemma 1.3 In any lts (S , Act, −
→) strong bisimulation equivalence ∼bis is an
equivalence relation.
Proof: We have to show that ∼bis is reflexive, symmetric and transitive.
reflexive: The identity relation over states,
{ (P, P) | P ∈ S }
is easily shown to be a bisimulation, and therefore is contained in strong
bisimulation. Consequently P ∼bis P for every element P in S .
symmetric: Individual bisimulations are not necessarily symmetric. But because
of the symmetry of the transfer property it is easy to check that the largest
bisimulation is symmetric. Let
R = { Q, P
| P ∼bis Q }
This is easily shown to be a strong bisimulation, from which the symmetry
of ∼bis follows.
transitive: Let R be the set of all pairs P, Q
such that there exists some R such
that P ∼bis R and R ∼bis Q. Using the symbol ◦ to denote the composition of
relations, R could be defined to be (∼bis ) ◦ (∼bis ). Then one can show that R is
a strong bisimulation. For example suppose P R Q and P −→ a
P  ; we must find
a matching move from Q, that is some Q −→ Q such that P R Q .
a  

We know that for some R, P ∼bis R and R ∼bis Q. So there exists a matching
move from R, that is some R −→ a
R such that P  ∼bis R . Furthermore this
move from R can be matched by one from Q: there exists some Q −→ a
Q
 
such that R ∼bis Q . But this is the required matching move, since by
definition P  R Q .

1.3 Bisimulation equivalence

The operational behaviour of processes will be described using an lts. In many
cases this involves having a special action label in Act, called τ , to represent
unobservable internal activity; other elements in Act will usually represent some
form of observable behaviour, that is behaviour that can be seen, or provoked, by
external observers. The special nature of the action τ requires a revision of the
notion of strong bisimulation.
 1.3 Bisimulation equivalence 7

Example 1.4 Consider the two machines M , N defined by

a.b. stop a.τ .b. stop

respectively. According to our definition we have M  ∼bis N , although it is difficult

to imagine a scenario in which external users would be able to perceive a difference
in their behaviour.

We need to revise our definition so as to abstract away from internal actions.

a
Again we suppose an arbitrary lts (S , Act, −→) in which Act = eAct ∪ {τ }. For
∗
every sequence s ∈ eAct we can define the corresponding weak action
s
P =⇒ Q

in which P can evolve to Q performing the visible actions in s, interspersed with

arbitrary sequences of internal actions. Formally, if s = α1 α2 . . . αn , n ≥ 0, where
αi ∈ eAct, this means that
τ ∗ α1 τ ∗ α2 τ ∗ τ ∗ αn τ ∗
P −→ −→ −→ −→ −→ . . . −→ −→ −→ Q
ε τ ∗
Note that if ε represents the empty sequence then P =⇒ Q means that P −→ Q.
Now we can revise our definition of bisimulations, using this new notion of
action.
a
Definition 1.5 (bisimulations) A relation R over the states S of the lts (S, Act, −→)
is called a bisimulation if it satisfies the following transfer property:
• P1 R P2 and P1 =⇒ P1 implies P2 =⇒ P2 for some state P2 such that P1 R P2
s s

• P1 R P2 and P2 =⇒ P2 implies P1 =⇒ P1 for some state P1 such that P1 R P2
s s

for every s in eAct∗ . Diagrammatically we require both R and its inverse to satisfy:

As with strong bisimulations, we know that the largest bisimulation exists and
we denote it by ≈bis . Moreover it comes with its own form of coinduction: for
example to show P ≈bis Q it is sufficient to exhibit a bisimulation containing
8 Inductive principles

the pair P, Q
. For example a.b. stop ≈bis a.τ .b. stop because the following is a
bisimulation:
a.b. stop ↔ a.τ .b. stop
b. stop ↔ τ .b. stop
b. stop ↔ b. stop
stop ↔ stop
We can also use coinduction in more general reasoning about the equivalence ≈bis ;
for example we can mimic the arguments given above for ∼bis to prove that ≈bis
is an equivalence relation.
To prove that a relation has the transfer property, as currently formulated, is quite
onerous; there is a quantification over all sequences s of action labels from eAct∗ .
It turns out that this can be considerably relaxed; it is sufficient to match strings of
length at most one. In fact we can go further and demand only that strong actions,
µ
P1 −→ P1 where µ ranges over Act, be matched; of course this matching may be
done by a weak action, one allowing an arbitrary number of interspersed internal
actions.
Definition 1.6 (simple bisimulations) First some notation. For any µ ∈ Act let
µ̂
P1 =⇒ P1 mean
µ
• P1 =⇒ P1 if µ is an external action label, that is an element of eAct
τ
• P1 −→∗ P1 if µ is the internal action τ .

Then we say a relation R over the states of an lts is a simple bisimulation if it

satisfies the following transfer property, for every µ in Act:
µ µ̂
• P1 R P2 and P1 −→ P1 implies P2 =⇒ P2 for some state P2 such that P1 R P2
µ µ̂
• P1 R P2 and P2 −→ P2 implies P1 =⇒ P1 for some state P1 such that P1 R P2 .

Diagrammatically we require R and its inverse to satisfy:


α
Thus we demand that a strong external action, P1 −→ P1 where α ∈ eAct, be
α
matched by a weak external action P2 =⇒ P2 but allow single internal actions,
 1.3 Bisimulation equivalence 9
τ
P1 −→ P1 , to be matched by an action consisting of a series of zero or more internal
τ ∗ 
actions P2 −→ P2 .
Theorem 1.7 If P1 R P2 , where R is a simple bisimulation, then P1 ≈bis P2 .
Proof: It suffices to show that R is a bisimulation. Suppose P1 =⇒ s
P1 . We find
the matching move by induction on the overall size of the derivation of P1 =⇒s
P1 .
Then there are three possibilities:
• The sequence s is empty , and indeed the entire derivation sequence is empty, that is

P1 =⇒ P1 because P1 is P1 .

In this case the matching move is also the trivial move P2 =⇒ P2 .
α s 
• The derivation can be deconstructed into P1 −→ Q1 =⇒ P1 , where α is an external action.
In this case s has the form α.s .
We can use the fact that R is a simple bisimulation to find a corresponding weak action
α s
P2 =⇒ Q2 such that Q1 R Q2 . But now we can apply induction to the move Q1 =⇒ P1 ,
s
to obtain a matching move Q2 =⇒ P2 such that P1 R P2 . These two moves can now be
α.s
combined to give the required matching move P2 =⇒ P2 .
τ
• The derivation can be deconstructed into P1 −→ Q1 =⇒ P1 .
s
τ ∗
Here we again apply the definition of simple bisimulations to obtain a move P2 −→ Q2
s
such that Q1 R Q2 . As in the previous case induction gives a move Q2 =⇒ P2 such that
P1 R P2 , and these two moves can be again combined to give the required matching move
P2 =⇒s
P2 .

It is this form of bisimulation that we use throughout the book, and we will omit
the qualifier simple. For the various languages considered we give an operational
semantics in the form of an lts. Intuitively
• The states will consist of the collection of processes that can be defined using the language;
sometimes these will be more general configurations consisting of processes combined
with interfaces to external users.
• The action labels, which will always include τ , will be the different ways in which we
believe users or observers can interact with processes.
µ
• The next-state relations −→, defined inductively, will represent the manner in which these
interactions can change processes.

Given this framework we immediately obtain a behavioural equivalence ≈bis for the
processes definable in the language. As we have seen this equivalence automatically
comes equipped with powerful coinductive proof techniques. Their properties will
be developed, using the notion of simple bisimulations, rather than the original one
from Definition 1.5.
 2
The asynchronous pi-calculus

Here we describe a simple language in which values are exchanged between

concurrent processes via communication channels. These channels can be used
to model resources and the syntax allows them to be declared as private, for the
exclusive shared use of specific processes. The names of these channels/resources
can also be transmitted between processes, resulting in a very powerful descriptive
language.
We give two different views of the language. The first, via a reduction semantics,
describes how processes may evolve. This may be seen as a specification of an
interpreter for the language and is taken to be the primary semantic definition. The
second view is an action semantics, which describes how processes can interact with
other processes, perhaps as part of a larger system; this describes how processes can
behave as part of a larger endeavour. This second view interprets the language as
a labelled transition system or lts, as explained in Definition 1.2, and thus induces
automatically a bisimulation equivalence between processes.

2.1 The language API

The syntax of the language aPi is given in Figure 2.1. It presupposes a set
Names of names, ranged over by n, m, . . . , a, b, c . . . for communication channels
or resources. We also use a set Vars of variables, place-holders for values that can
be transmitted via the communication channels. These values will include some
unspecified collection of base values such as integers, booleans, strings, etc., ranged
over by bv, but more importantly channel names themselves. We will reserve
the meta-variable u for identifiers, that is either names or variables. The intuitive
meaning of each of the syntactic constructs is as follows:
• The simplest possible process, which does nothing, is represented by the term stop.
• The term c! V
represents the next simplest process, which can transmit the value V along
the channel c. Values V are structured, taking the form (v1 , . . . , vk ), where vi are

10
 2.1 The language aPi 11

Figure 2.1 Syntax for aPi

Figure 2.2 Patterns and values in aPi

simple values; these in turn consist of identifiers or basic values. See Figure 2.2 for
their syntax. The value V = (v1 , . . . , vk ) is said to have arity k.
• Input from a channel c is represented by the term c?(X ) R, where X is a pattern that may be
used to deconstruct the incoming value. Patterns are constructed by the tupling together
of variables, as described in Figure 2.2; for simplicity we also assume occurrences of
variables in patterns are always unique. The process c?(X ) R may input a value V along
the channel c, deconstruct it using the pattern X and then execute R into which the
components of V have been substituted, which we will denote by R{|V/X |}; see Notation 2.1
below.
• if v1 = v2 then R1 else R2 is a test for the identity of simple values.
• R1 | R2 represents two processes running in parallel; they may exchange values using
input/output on channels.
• (new n) R is a scoping mechanism for names. For example in the process

R1 | (new n) R2

the name n is known to R2 but not to R1 ; of course names are values and so in the course
of a computation n may be made known to R1 as the result of a communication; this will
be referred to as the scope extrusion of the name n.
12 The asynchronous PI-CALCULUS

• rec x. B is a mechanism for defining recursive processes. Here B, a process term,

represents the body of the recursive definition, and occurrences of x within B stand
for recursive calls. A more elaborate mechanism would allow these definitions to be
parameterised over, for example, values. Note that we do not distinguish between the
variables used in recursive definitions, and those used as placeholders for values; this is
simply to avoid additional notational complexity.

The term F1 (b, c), defined by

F1 (b, c) ⇐ rec z. b?(x) (c! x
| z)
represents a simple process that repeatedly receives a value on channel b and
forwards it along channel c. Note that this definition is purely notational. We
simply mean that F1 (b, c) is used as a shorthand notation for the process term
rec z. b?(x) (c! x
| z); we will use this device extensively. Two such forwarding
processes can be run in parallel, as for example in

FF1 ⇐ (new c)(F1 (b, c) | F1 (c, d ))

where F1 (c, d ) is given by
F1 (c, d ) ⇐ rec z. c?(x) (d ! x
| z)
In the system FF1 the two concurrent processes F1 (b, c) and F1 (c, d ) share a
common local channel c along which they may communicate. F1 (b, c) can input a
value along b and make it available to F1 (c, d ) at channel c; F1 (c, d ), on receipt
of the value, may in turn make it available at d . The restriction operator (new c)
ensures that the channel c is private to FF1 ; no process other than F1 (b, c) and
F1 (c, d ) can use it.
Note that in FF1 , F1 (b, c) may input a second value before F1 (c, d ) reads the first
one from the internal channel c. Consequently FF1 , viewed as a forwarder from
channel b to d , will not necessarily preserve the order of values transmitted. The
basic problem is that outputs are asynchronous; having transmitted a value there is
no guarantee that the recipient has actually consumed it. However we can use the
power of aPi to transmit channel names to set up a simple communication protocol
in which senders await an acknowledgement each time a value is transmitted.
Suppose we have at our disposal a channel named ack. Then in
c! v, ack
| ack?() R
a value v is transmitted on c together with the channel ack. The continuation R
is then only executed once an acknowledgement has been received on ack. The
receiving process is expected to send this acknowledgement, via the simple process
ack! ()
, whenever a value is received on c. Here the notation () means an empty
 2.1 The language aPi 13

tuple of values; that is no value is sent and the channel ack is simply used for
synchronisation. However in future, to avoid the proliferation of brackets, we will
render the transmission along these synchronisation channels simply by ack!
.
This also explains the input notation. In ack?() R the syntax() represents the empty
pattern. That is no data is expected on the channel; more correctly this process
should be rendered as ack?(()) R.
This acknowledgement scheme is used in the following revision of the forwarder:
F2 (b, c, ack) ⇐ rec z. b?(x, y) ( c! x, ack
| ack?() (y!
| z))
Here the input channel b receives from a source client a value to be forwarded, bound
to x, and an acknowledgement channel, bound to y. The value is then output to the
destination client on the channel c, together with the name of the acknowledgement
channel ack. At this point the acknowledgement is awaited on ack; when it is
received the original acknowledgement, bound to y, is sent to the source client, and
the forwarder is ready for a new input on channel b.
Now consider the revised system
FF2 ⇐ (new c)(F2 (b, c, ack) | F2 (c, d , ack))
where F2 (c, d , ack) is defined by replacing b, c in F2 (b, c, ack) with c, d
respectively. Here there is more hope of the order of values forwarded from
b to d being preserved. But there is confusion about the use of the channel
ack; it is used to arrange acknowledgements internally, between the two internal
systems F2 (b, c, ack) and F2 (c, d , ack), and externally, between the system and the
destination client. Moreover these two distinct roles can become intertwined.
Instead of the individual components F2 (b, c, ack) and F2 (c, d , ack) relying on
a globally available channel ack, an alternative, defensive, strategy would be for
these forwarders to generate a new acknowledgement channel for each particular
communication, with each acknowledgement channel being used exactly once.
Here is how such a forwarder would look:
F(b, c) ⇐ rec z. b?(x, y) (new ack)(c! x, ack
| ack?() (y!
| z))
A system forwarding values from b to d in order using such forwarders would be
defined by:
FF ⇐ (new c)(F(b, c) | F(c, d ))
where F(c, d ) is obtained in the obvious manner from F(b, c).
At this stage, before we give further examples that rely on the transmission of
newly generated channels, it is best if we first define a formal semantics that will
explain in detail how this mechanism works. Using this formal semantics we can
then investigate the actual behaviour of processes such as FF, and see whether this
14 The asynchronous PI-CALCULUS

in fact coincides with our intuitive understanding. To do so we need to develop

some notation: much, but not all, standard.
Notation 2.1 Terms defined by the grammar in Figure 2.1 in general contain
occurrences of variables, place-holders for names or processes, and these variables
may be bound using the input and recursion constructs; these are called binders for
variables. If the variable x occurs in the pattern X then all occurrences of x in the
sub-term R of c?(X ) R are said to be bound ; similarly with all occurrences of x in
the sub-term B of rec x. B. All occurrences of variables that are not bound in a
term are said to be free. We use fv(R) to denote the set of variables that occur free
in R, and bv(R) those that occur bound.
Informally we will refer to a closed term, a term P such that fv(P) = ∅, as a
process. Intuitively they do not require any instantiation of their variables in order
to make sense.
In aPi we also have a binder for names; in the term (new n) R, which may be a
process, all occurrences of the name n in R are said to be bound, and we use fn(R),
bn(R), to denote the set of all names that occur free, bound respectively, in R.
As with any language containing binders we have a modified notion of
substitution of simple values into variables. If v is a simple value, then
R{|v/x|}
is the result of substituting v for all free occurrences of x in R, in such a manner that
v is not captured by any binding constructs c?(X ) (−), rec x. − or (new n)(−).
Note that this result may not be a well-defined term; for example x may be playing
the role of a recursion variable in R.
Example 2.2 Substituting n for x in the term c?(y, z) (d ! y, x
| b! z, x
) gives the
term c?(y, z) (d ! y, n
| b! z, n
). In other words
(c?(y, z) (d ! y, x
| b! z, x
)){|n/x|} = c?(y, z) (d ! y, n
| b! z, n
)
On the other hand
(c?(y, z) (d ! y, x
| b! z, x
)){|y/x|} = c?(w, z) (d ! w, y
| b! z, y
)
where the new variable w is chosen to be different from the existing free and bound
variables. Intuitively the behaviour of a process is independent of the actual identity
of bound variables as they are merely place-holders. So here we have renamed the
bound variable y so that when the substitution of y for x is made, what was previously
a free variable, x, is not transformed into a bound variable.

This is generalised to the substitution of a structured value V for a pattern, denoted
R{|V/X |}; again for this to be well-defined we require at least that the structure of V
and X match. It is best also to assume that each variable has at most one occurrence
 2.1 The language aPi 15

in any pattern. So the substitution of V for X in R can be defined, inductively on

the structure of X , as a sequence of substitutions of simple values.
In a similar manner we can define R{|n/m|}, the capture-avoidance substitution of
the name n for free occurrences of the name m in T . These notions of substitution
then lead, in the standard manner, to a notion of α-equivalence between terms:
R1 ≡α R2
Intuitively this means that R1 and R2 are the same terms except in their use of bound
identifiers.
Example 2.3 The process c?(y, z) (d ! y, x
| b! z, x
) has the same behaviour as
c?(z, w) (d ! z, x
| b! w, x
) as only the place-holders for incoming values have
been changed. Formally we have
c?(y, z) (d ! y, x
| b! z, x
) ≡α c?(z, w) (d ! z, x
| b! w, x
)
In a similar manner, assuming m does not appear in P,
(new n)(c! n
| n?(x) P) ≡α (new m)(c! m
| m?(x) (P{|m/n|}))


We will identify terms up to α-equivalence, or more formally use terms as
representatives of their α-equivalence classes.
Convention 2.4 (Barendregt) This identification of terms up to α-equivalence
allows us to use a very convenient convention when writing terms. We will always
ensure all bound identifiers are distinct, and chosen to be different from all free
identifiers. In fact we will go further, ensuring that this freshness of bound identifiers
is true relative to the context in which the term is being used. We will refer to this
as the Barendregt convention. 
Finally let us consider the most general form of substitution. Let σ be any
mapping between values. The result of applying this substitution to a term R will
be denoted Rσ . It is obtained by systematically replacing all free occurrences of
values v, including identifiers, with σ (v). Of course bound variables are renamed as
necessary to ensure no capture of free names or variables; for example ((new n) R)σ
could be defined to be (new m)(R(σ [n → m]), where m is chosen to be fresh, and
σ [n → m] is the renaming that is identical to σ except that it maps n to m. Here fresh
means distinct from all of σ (n), for n in fn(R). Nevertheless there is no guarantee
that the result will be a well-defined term; for example a basic value such as an
integer may be substituted for a channel name. However these general substitutions
will only ever occur in the questions at the end of chapters. In the body of the text
we will only use the forms of substitution already discussed above, R{|m/n|}, R{|V/X |},
which of course are particular instances of Rσ .
16 The asynchronous PI-CALCULUS

2.2 Reduction semantics for aPi

There are at least two standard methods for giving a formal operational semantics
to a language such as aPi. One, called reduction semantics, describes the allowable
computations from individual processes, while the other, which we will refer to as lts
semantics, describes the possible ways a process may interact with its environment,
and the consequences of these interactions. The latter will be discussed in length
in Section 2.3, while here we describe the former.
The reduction semantics is defined as a binary relation −→ between closed terms
or processes. The judgement
P −→ Q
intuitively means that in one computation step the process P reduces to Q. A
computation from P then consists of an arbitrary number of such steps from P;
we will use −→∗ as the reflexive transitive closure of −→; thus
P −→∗ Q
means that a computation from P may lead to Q.
The reduction semantics takes a relaxed view of the syntax of processes,
informally interpreting terms spatially. For example intuitively the term
P | Q
represents two computational processes, P and Q, running in parallel. Formally, as
a term, it is different from
Q | P
although, intuitively, this term represents exactly the same computational entity;
we do not wish to consider it significant that one thread is running at the left, or at
the right, of another.
Exactly what terms we consider to represent precisely the same computational
entity is to some extent a question of taste. It can be expressed by defining an
equivalence relation ≡ between processes, the interpretation being that if P ≡ Q
then the terms P and Q are so similar that we do not wish to differentiate between
them when viewed as computational entities.
Definition 2.5 (contextual) We say a relation R over processes is contextual if it
is preserved by the so-called static operators of the language. That is, if P1 R P2
implies
• P1 | Q R P2 | Q and Q | P1 R Q | P2 for every process Q
• (new n) P1 R (new n) P2 for every name n. 
 2.2 Reduction semantics for aPi 17

An alternative formulation of contextual is obtained by explicitly defining the set of

static contexts. These are terms with a special marker –, defining a hole into which
processes can be placed.
Definition 2.6 (contexts) The set of (static) contexts for aPi is the least set of
extended terms such that
• – is a static context
• if C[−] is a static context then so are C[−] | Q and Q | C[−] for every process Q
• if C[−] is a static context then so is (new n) C[−] for every name n.

Note that every static context contains exactly one occurrence of the marker −. 
For any process P we let C[P] denote the process that results from syntactically
replacing the occurrence of − with P in C[−]. Note that this replacement is very
different from the notion of substitution defined in Notation 2.1; here names that
are free in P may become bound when placed in the context C[−]. For example
if C[−] is the context (new b)(− | R) and P is the process a! b
then C[P] is the
process (new b)(a! b
| R); the free name b in P has become bound.
Now we can see that a relation R over processes is contextual if and only if it is
preserved by (static contexts); that is P R Q implies C[P] R C[Q] for every static
context C[−]; see Question 1 at the end of the chapter.
Returning to the discussion on equating certain processes we take ≡, referred
to as structural equivalence, to be the least relation between processes (i.e. closed
terms) that
(i) extends α-equivalence
(ii) is an equivalence relation; that is, is reflexive, symmetric and transitive
(iii) is contextual
(iv) and satisfies the axioms in Figure 2.3.

The condition (i) is only mentioned for emphasis; in reality, since we view terms
as representing equivalence classes, it is redundant. Condition (ii) means that ≡
acts like an identity relation over terms. Condition (iii) just means that the axioms
in Figure 2.3 can be applied anywhere in static contexts. The axiom (s-stop) is a

Figure 2.3 Structural equivalence for aPi

18 The asynchronous PI-CALCULUS

Figure 2.4 Reduction semantics for aPi

form of garbage collection; it is possible to derive a more general form of garbage

collection, namely
(new n) P ≡ P if n  ∈ fn(P)
See Question 6 at the end of the chapter. The axiom (s-flip) says that the order
in which new names are generated is not important. The most significant rule is
(s-extr); as we shall see it is this rule that underlies the formal definition of scope
extrusion.
Note that this definition of structural equivalence is an example of an inductive
definition, as outlined in Section 1.1. Consequently there is a form of rule induction
associated with ≡, which can be used to prove properties of it; the first application
of this proof method will be in the proof of Lemma 2.13 below.
Formally the reduction semantics −→ is defined to be the least contextual
relation that satisfies the rules given in Figure 2.4. There are three axioms. The
most important is (r-comm), which states that a computation step can occur by
the transmission of a value V along a channel c. Of course in general the resulting
substitution R{|V/X |} may not be meaningful because the structure of V and the
pattern X may not match. So these rules should be interpreted as giving axioms
only when all terms involved are well-defined. In the next chapter we will develop
type systems that will ensure that such ill-defined substitutions will never occur.
The axiom (r-unwind) dictates that the reductions of a recursively defined process
are determined by those of its body and again is subject to the substitution being
well-defined. The axioms (r-eq) and (r-neq) allow the testing for equality between
values. Finally the rule (r-struct) effectively says that reduction is defined up to
structural equivalence. As we shall see it is this rule that gives much of the power
to the reduction semantics.
Let us now look at some examples to see how these rules can be used to infer
computations of processes.
 2.2 Reduction semantics for aPi 19

Example 2.7 Consider the process FF1 discussed above:

FF1 ⇐ (new c)(F1 (b, c) | F1 (c, d ))

The only possible reduction from this process is an unwinding of one of these
recursive definitions. It is instructive to see how such a step can be inferred from
the definition of the reduction relation −→. Recall that F1 (b, c) represents the
recursive process rec z. b?(x) (c! x
| z), and therefore an instance of the reduction
rule (r-unwind) gives

F1 (b, c) −→ b?(x) (c! x

| z){|F1 (b,c)/z|}

since b?(x) (c! x

| z) is the body of the recursive definition. Performing the
substitution this equates to

F1 (b, c) −→ b?(x) (c! x

| F1 (b, c))

For notational convenience let us use B(b, c) to denote the residual of this
judgement, namely b?(x) (c! x
| F1 (b, c)). So in summary one application of
(r-unwind) gives

F1 (b, c) −→ B(b, c)

Let us now see how this reduction can take place as part of the larger system
FF1 . The fact that −→ is contextual means that it satisfies two inference rules,
which essentially say that the rules in Figure 2.4 may be applied anywhere under
occurrences of the static operators | and (new n):
(r-par) (r-new)
P −→ P P −→ P 
P | Q −→ P  | Q (new n) P −→ (new n) P 
Q | P −→ Q | P 
So we have the following formal derivation, where the inferences are justified by
the rules used:
1 F1 (b, c) −→ B(b, c) (r-unwind)
2 F1 (b, c) | F1 (c, d ) −→ B(b, c) | F1 (c, d ) (r-par) to 1
3 FF1 −→ (new c)(B(b, c) | F1 (c, d )) (r-new) to 2
In other words one possible computation step from the system FF1 is given by

FF1 −→ (new c)(B(b, c) | F1 (c, d ))

Nevertheless these unwindings, even within static contexts, do not lead to

interesting computations. After the second unwinding, via an application of
20 The asynchronous PI-CALCULUS

(r-unwind) to the other recursive process F1 (c, d ), no more reductions are possible;
the system is in a stable state awaiting input on c:
(new c)(B(b, c) | B(c, d ))
However we can place FF1 in a context in which the channels b and d are used:
b! v
| FF1 | d ?(x) print! x
(2.1)
Note that here we are implicitly using the structural equivalence; formally we should
write
(b! v
| FF1 ) | d ?(x) print! x
or b! v
| (FF1 | d ?(x) print! x
)
But these terms are structurally equivalent and because of the rule (r-struct) it
does not actually matter which we use. Consequently when writing down a number
of processes in parallel we omit the bracketing. Let us refer to this initial process,
(2.1) above, as Sys1 .
Here once more the only possible initial moves are these unwindings of the
recursive definitions, which gives
Sys1 −→∗ b! v
| (new c)(B(b, c) | B(c, d )) | d ?(x) print! x
(Sys2 )
and let us refer to this latter process as Sys2 . At this point, to obtain a reduction,
we will need to use the rule (r-struct), using the fact that
b! v
| (new c)(B(b, c) | B(c, d )) ≡ (new c)(b! v
| B(b, c) | B(c, d )) (2.2)
Here the private channel c has been extruded, using the structural rule (s-extr),
to allow the inference of the communication along the channel b. This inference
uses the axiom (r-comm), followed by an application of the rule (r-par) and then
(r-new), to give the reduction
(new c)(b! v
| B(b, c) | B(c, d )) −→ (new c)(c! v
| F1 (b, c) | B(c, d )) (2.3)
Thus an application of (r-struct) to (2.2) and (2.3), followed by (r-par), gives
the reduction
Sys2 −→ (new c)(c! v
| F1 (b, c) | B(c, d )) | d ?(x) print! x
(Sys3 )
At this point, in Sys3 , communication is possible along the channel c, at least
intuitively, but to formally derive it we again need various applications of the rules.
The basic axiom used is
c! v
| B(c, d ) −→ d ! v
| F1 (c, d )
an instance of (r-comm). An application of (r-par), then (r-struct), then
(r-new), then (r-par), gives:
Sys3 −→ FF1 | d ! v
| d ?(x) print! x
(Sys4 )
 2.2 Reduction semantics for aPi 21

In a similar manner the communication of v on d can be derived, cumulating in the

overall derivation
Sys1 −→∗ FF1 | print! v

Such a sequence of individual reductions, each derivable from the defining rules of
the reduction semantics, is called a computation. The initial state of this computation
is Sys1 , and the terminal state is the process FF1 | print! v
. Note that this terminal
state is stable; there is no further reduction that can be made from it.
There are slight variations in the possible computations starting from the initial
state Sys1 , essentially caused by the unwinding of recursive definitions. But it is
possible to prove that
• all are finite; they must end in a stable state, from which no further reductions are
possible
• all these stable states are structurally equivalent to (FF1 | print! v
).

Convention 2.8 (syntactic abbreviations) When writing processes we assume that

the input and restriction operator binds more strongly than parallel composition.
We will also use brackets to help disambiguate terms where necessary and freely
use Barendregt’s convention to ensure bound names and variables are unique.
We will often abbreviate (new n1 ) . . . (new nk ) P to (new ñ) P and render
c?() T , c!
as c?T , c! respectively. Finally trailing occurrences stop will some-
times be omitted. 

In the next example we see how the reduction semantics correctly handles
dynamically created channels, and their scoping.
Example 2.9 Consider the forwarder from b to c, defined by
F(b, c) ⇐ rec z. b?(x, y) (new ack)(c! x, ack
| ack?(y! | z))
Such forwarders can be combined together as in the previous example but their
use requires that an implicit protocol be followed. Consider the new system Sys
defined by
Sys ⇐ User | FF | Print
The composite forwarder FF, defined in Section 2.1, consists of two forwarders
linked together:
FF ⇐ (new c)(F(b, c) | F(c, d ))
The User sequentially supplies two values to the system,
User ⇐ (new ack1 )(b! v1 , ack1
| ack 1 ? (new ack2 ) b! v2 , ack2
)
22 The asynchronous PI-CALCULUS

and the process Print inputs two values sequentially from channel d and prints the
second one,
Print ⇐ d ?(x1 , x2 ) (x2 ! | d ?(y1 , y2 ) (y2 ! | print! y1
))
In Sys the only possible initial reductions are, once more, the unwindings of the
recursive definitions, giving
Sys −→∗ User | (new c)(B(b, c) | B(c, d )) | Print (Sys1 )
Here we use B(−, −) to denote the result of unwinding the definition of a forwarder;
for example B(b, c) represents b?(x, y) (new ack)(c! x, ack
| ack?(y! | F(b, c))).
At this stage, intuitively, communication is possible along the channel b between
User and FF. However the axiom (r-comm) can only be applied if c and also
ack1 , part of the value being communicated, is first extruded using (s-extr). One
possible rearrangement using the structural rules is given by
Sys1 ≡ (new c, ack1 )(User | (B(b, c) | B(c, d ))) | Print
because c and ack1 do not occur in User. Now the axiom (r-comm) can be applied
to User | B(b, c), and subsequently using (r-par) and (r-new) we obtain
(new c, ack1 )(User | (B(b, c) | B(c, d ))) −→ (new c, ack1 )
(User1 | (B1 (b, c) | B(c, d )))
where User1 and B1 (b, c) represent the obvious processes,
ack1 ? (new ack2 ) b! v2 , ack2
and (new ack)(c! v1 , ack
|ack?(ack1 !|F(b, c)))
respectively. So an application of (r-par) and (r-struct), gives
Sys1 −→ (new c, ack1 )(User1 | B1 (b, c) | B(c, d )) | Print (Sys2 )
Note that a priori, from the syntactic form of Sys2 , it may seem that c is actually
shared between the user and the composite forwarder. However Sys2 is structurally
equivalent to
(new ack1 )(User1 | (new c)(B1 (b, c) | B(c, d ))) | Print
a term that gives a truer picture of the sharing of resources.
In Sys2 an internal communication within the forwarder, of the value v1 along
the channel c, is now possible. This leads to the reduction from Sys2 to
(new c, ack1 )(User1 | (new ack)(ack?(ack1 ! | F(b, c)) | B1 (c, d ))) | Print
(Sys3 )
where B1 (c, d ) represents (new ack2 )(d ! v1 , ack2
| ack 2 ?(ack! | F(c, d ))); for
the sake of clarity, and to comply with Barengregt’s convention, we have used
 2.2 Reduction semantics for aPi 23

α-conversion to rename the second acknowledgement used in the forwarder, from

ack to ack 2 . In Sys3 there are now two acknowledgements awaiting reception and
there is a possible communication between the forwarder and the print process along
the channel d . However, to formally deduce this communication as a reduction,
we need to use (s-extr) to extrude the new acknowledgement channel ack 2 to the
surrounding system. This in turn requires the extrusion of the local channels c, ack
and ack 1 , or the use of (s-flip), and, after the application of many rules we obtain
the reduction
Sys3 −→ Sys4
where Sys4 represents the process
(new c, ack1 , ack, ack2 )(User1 | (ack?(ack 1 ! | F(b, c))
| ack2 ?(ack! | F(c, d )) | Print1 )
Here Print1 is shorthand for the process
ack 2 ! | d ?(y1 , y2 ) y2 ! | print! y1

At this point there are three acknowledgements awaiting reception and no further
communications along b, c or d are possible until at least some are delivered. In fact
progress depends on the acknowledgement ack2 from the printer being delivered
to the second forwarder; this will liberate the acknowledgement ack, which when
delivered will in turn liberate ack1 , on which User1 is waiting. This leads to the
series of reductions
Sys4 −→∗ (new c, ack1 , ack, ack2 )(User2 | F(b, c) | F(c, d ) | Print2 ) (2.4)
where User2 represents
(new ack2 ) b! v2 , ack2

and Print2 the process

d ?(y1 , y2 )y2 ! | print! y1

However the current term can be simplified considerably using the derived structural
equation already mentioned:
(new n) P ≡ P if n  ∈ fn(P)
The channels ack1 , ack and ack2 do not occur freely in the residual process in (2.4)
and therefore applying this rule we obtain
(new c, ack 1 , ack, ack2 )(User2 | F(b, c) | F(c, d ) | Print2 )
≡ (new c)(User2 | F(b, c) | F(c, d ) | Print2 )
24 The asynchronous PI-CALCULUS

and since c does not appear freely in User2 and Print2 we can apply (s-extr) to
obtain
(new c)(User2 | F(b, c) | F(c, d ) | Print2 ) ≡ User2 | FF | Print2
Thus an application of (r-struct) to (2.4) above gives
Sys4 −→∗ (User2 | FF | Print2 ) (Sys5 )
In Sys5 the user may send the second value, which eventually makes its way
through the system, followed by a series of acknowledgements travelling in the
opposite direction.

We have just seen one possible computation from the system
User | FF | Print
Again there are possible variations, depending on recursive unwindings. But again
it is possible to prove that all must terminate and the resulting stable process must be
structurally equivalent to FF | print! v2
. This shows that the values are forwarded
through the composite forwarder in a sequential manner. This should be contrasted
with the possible computations from
User | FF1 | Print
where FF1 is the simple composite forwarder, which uses no acknowledgements.
This system can indeed evolve to a stable state, similar to the one above,
namely FF1 | print! v2
. But it may also evolve to the very different stable state
FF1 | print! v1
, in which the first value sent is actually printed. These two
possibilities constitute a formal demonstration that the first composite forwarder
does not necessarily forward values in sequence.
In the next example we see a very powerful use of the dynamic creation of
channels. With them we can give a very simple definition of compute servers,
which can service an arbitrary number of independent clients, even clients who are
not known when the servers are originally installed.
Example 2.10 [A Compute Server] A compute server, when given some appropriate
data, performs a specific computation on the data and returns the result. We will
abstract from the details of the actual computation, representing it as an operation
on values. To be specific let us assume an operation isprime that takes an integer
and returns true or false, depending on whether the input is prime. Then the
corresponding compute server is defined by
primeS ⇐ rec z. inp ?(x, y) (z | y! isprime(x)
)
At the service point inp a pair of values is received, the first of which should be
an integer and the second a channel. The integer is tested for primality and the
 2.2 Reduction semantics for aPi 25

result is returned on the received channel. The recursive definition ensures that the
service is always available and can handle an arbitrary number of calls. The use of
isprime is meant to signify some auxiliary computation, the details of which are not
of interest. However in a more expressive language the body of the server would
be better written as
inp ?(x, y) (z | let a = isprime(x) in y! a
)
emphasising that the auxiliary computation is performed eagerly by the server.
The interest in sending a reply channel with the data is to ensure that different
calls to the service are not confused. For example if Client1 sends the value 27 and,
more or less at the same time, Client2 sends 29 then we have to ensure that the first
receives the answer false and the second true, and not vice-versa. To make this
clear let us define these clients:
Clienti (v) ⇐ (new r)(inp ! v, r
| r?(x) printi ! x
)
The client generates a new return channel r, sends it together with an integer v,
awaits the result on the reply channel, and prints it. Now consider the system
Sys ⇐ Client1 (27) | Client2 (29) | primeS
Each client can access the service in any order, and their respective interactions with
the service can even overlap. But we are assured that only false will be available
at print1 and only true at print2 . In particular if
Sys −→∗ Q
where Q is a stable process, then it is structurally equivalent to the process
print1 ! false
| print2 ! true
| primeS


We give one more example of the power of communication channels, showing
how they can be used to implement a notion of state or memory.
Example 2.11 [A Memory] A channel may be viewed as a very restricted form of
memory cell, where, unlike a normal memory cell the value it contains disappears
once it is read. However we can use it to mimic a standard memory cell if we ensure
that the current value is reinstated each time it is read. This is the idea behind the
following process, which uses a private resource s in which to store the current
value:
Mem ⇐ (new s)(s! 0

| rec g. get?(y) s?(z) (y! z

| s! z
| g)
| rec p. put?(x, y) s?(z) (y! | s! x
| p))
26 The asynchronous PI-CALCULUS

The initial value is set to 0. There are then two methods for accessing the cell:
• To obtain the current value the user must send along the access channel get a return
channel that is bound to the variable y. The current value is read from s and sent to the
user along the return channel. In addition the value is reinstated in the local store s.
• To change the value of the cell a user must send the new value, which will be bound to x,
and an acknowledgement channel, to be bound to y. The current value is read from s and
ignored. The new value is installed and the user is sent an acknowledgement.

A typical client of Mem is defined as follows:

Client ⇐ (new a)(put! 4, a

| a? (new r)(get! r
| r?(x) print! x
))

The value 4 is sent together with a newly declared acknowledgement channel a.

When the acknowledgement has been received the value in the store is obtained,
using a newly declared return channel, and printed.
Using the reduction semantics one can show that the composite system

Client | Mem

will reduce to a term that is structurally equivalent to

print! 4
| Mem

Indeed up to structural equivalence this is the only stable term to which it can
reduce.
Consider a client that puts in two values, and then retrieves the current state of
the memory:

Client2 ⇐ (new a)(put! 4, a

| a? (new b)(put! 6, b
|
b? (new r)(get! r
| r?(x) print! x
)))

One can show that the composite system

Client2 | Mem

will reduce to essentially one stable state, namely

print! 6
| Mem

In all of the examples seen so far systems have been described in terms of
their components, together with communication channels, between them. However
this connectivity between the system components, such as users and servers, has
been relatively static, although various acknowledgement and reply channels are
 2.3 An action semantics for aPi 27

generated dynamically on demand. But aPi can also describe systems in which the
connectivity, that is the sharing of communication channels between processes, can
vary arbitrarily. For example consider the following server, for providing forwarders
between channels:
GenF ⇐ rec w. for?(f, t)(w | F(f, t))
where F(f, t) is shorthand for the recursive code
rec z. f?(x, y) (new ack)(t! x, ack
| ack?(y! | z))
The process GenF when it receives a pair of channels at for, say b, c, spawns off
the forwarder F(b, c) and concurrently awaits another request on for. Repeated
use of this server will lead to many different communication linkages being
established, some of which may subsequently disappear. So dynamically changing
communication topologies are very easy to program in aPi.

2.3 An action semantics for API

Here we give a different, more general, view of a process, describing how it would
behave when placed within a larger computational environment, consisting of other
processes. The possible interactions between a process and this larger environment
consist of the exchange of messages along channels common to both, although
the process may also decide to ignore the environment. Consequently this view
of a process may be given in terms of an lts, as defined in Definition 1.2, where
the actions represent its ability to send and receive values along channels, or to
compute internally.
We will define three judgements:
c?V
• P−
−→ Q: the ability of the process P to receive the value V along the channel c, with the
residual Q representing the resulting change in the process.
(b̃)c!V
• P −−−→ Q, where (b̃) ⊆ fn(V ) and c  ∈ (b̃): the ability of P to send a value V along
c, simultaneously exporting the set of names (b̃); that is we do not differentiate between
different orderings of the exported names. Again Q represents the residual of P after this
action has been performed.
τ
• P −→ Q: the reduction of P to Q by some internal activity. This will be defined in terms
of the first two judgements, and hopefully will be related to the reduction semantics in
Section 2.2.

Notation 2.12 The symbol αi will be used to range over all input action labels,
those of the form c?V , while αo will refer to an arbitrary output label, (b̃)c!V . We
will use α to represent an arbitrary external action label, input or output, while µ
will range over all possible actions; that is it may also include τ . We use bn(µ) to
denote the set of bound names in the action µ: if this is an input action then bn(α)
28 The asynchronous PI-CALCULUS

Figure 2.5 An action semantics for aPi

is empty, while if it is the output action (b̃)c!V then it is the set {b̃}. Finally n(µ)
denotes the set of names that appear anywhere in µ, while fn(µ), the free names in
µ, are those in n(µ) that are not in bn(µ).

It is worth emphasising that here we are not concerned with any external view of
these actions. We are simply defining, very intentionally, the ability of processes
to perform these actions rather than the ability of some observer to discern that
these actions have taken place. This more subtle viewpoint will be discussed in
Section 2.6.
These relations are defined to be the least relations between processes, that is
closed terms in aPi, which satisfy the inference rules in Figure 2.5. The first two
axioms, (l-in) and (l-out), are straightforward but note that the input move is only
possible when the substitution of V for X in R is well-defined.
The output axiom (l-out) needs no explanation. The rule (l-open) allows new
names to be exported. For example using this rule, and (l-out), we may deduce
that the process (new b) c! b
can export the new name b along the channel c:

(b)c!b
(new b) c! b
−
−−→ stop

However it is essential to note that (l-open) can only be applied when the resulting
action label (n)αo is well-defined; for example if α is c!V then this demands that n
is different from c, and that it appears in the value V .
 2.3 An action semantics for aPi 29
τ
The rule (l-comm), consisting of two symmetric rules, defines the action −→ as
the simultaneous occurrence of input and output actions. For example we have the
action
τ
c?(x) R | c! v
−→ R{|v/x|} | stop
The rule (l-comm) also implements scope extrusion. For example it can be used
to deduce
τ
c?(x) x! v
| (new b) c! b
−→ (new b)(b! v
| stop)
from the two prior judgements
c?b (b)c!b
c?(x) x! v
−→ b! v
and (new b) c! b
−
−−→ stop
A more interesting example is
τ
c?(x) (x! v
| P) | (new b)(c! b
| b?(x) R) −→ (new b)(b! v
| P|
stop |b?(x) R)
where we assume x does not occur in P. Here the process (new b)(c! b
| b?(x) R)
uses the channel c to send a private channel b to its partner, on which it, and only it,
can receive data. Its partner uses this newly acquired private channel to send some
private data, say v, resulting in the system
(new b)(stop |P | stop |R{|v/x|})
Since b is guaranteed not to occur in P this term is effectively the same as
P | R{|v/x|}
For example these two terms can be shown to be structurally equivalent. They
represent a system in which the original process has successfully obtained the
private data from its partner, and the private link between them used for the transfer
of this data has disappeared.
Note the side conditions in the rule (l-comm); the extruded names (b̃) should
not occur free in Q or otherwise those free occurrences would be captured in the
residual. So for example we can not deduce
τ
(c?(x) x! b
) | (new b)(c! b
) −→ (new b)(b! b
| stop) (2.5)
Intuitively the process (new b)(c! b
) is exporting some arbitrary but fresh name
along c and consequently it cannot be the same as the existing name b belonging
to its partner. However recall that processes are identified up to α-equivalence
and therefore we can take a different representative for (new b) c! b
, for example
(new d ) c! d
. Then with applications of (l-in) and (l-out), followed by a valid
30 The asynchronous PI-CALCULUS

application of (l-comm), since d is chosen not to occur freely in c?(x) x! b

, we
may deduce
τ
c?(x) x! b
| (new b)(c! b
) −→ (new d )(d ! b
| stop)
Note that this implicit method of working up to α-equivalence could be made
explicit by adding the inference rule:
(l-α)
µ
P −→ P  P ≡α Q
µ
Q −→ P 
to Figure 2.5. An alternative view is to say that (2.5) cannot be deduced because of
Barendregt’s convention, given on page 15. The process (c?(x) x! b
) | (new b)
c! b
should not be written because a bound name b is also free. Consequently it
should be replaced by an equivalent one respecting the convention, such as the one
we have used above.
The remaining rules in Figure 2.5 are straightforward; (l-unwind), (l-eq),
(l-eq) and (l-neq) are taken from the reduction semantics, while (l-cntx) allows
actions to be deduced in static contexts; again the side conditions ensure that no
free names inadvertently become bound.
τ
It is interesting to compare the definition of −→ with that of the reduction
τ
relation −→ of the previous section. The judgement P −→ Q is defined purely
in terms of the auxiliary input and output relations applied to P, and does not
explicitly use the structure of the process P. On the other hand the reduction
judgement P −→ Q relies heavily on the structure of P, and the use of the structural
equivalence ≡ in order to rearrange P so that the structure required for making a
reduction may be made explicit. This use of structural equivalence makes reduction
τ
−→ a much larger relation; it will relate many more processes than −→. Revisiting
Example 2.9 of the previous section we can derive
User | (new c)(B(b, c) | B(c, d )) −→ (new c, ack1 )(User1 | (B1 (b, c) | B(c, d )))
It is easy to see that the corresponding judgement
τ
User | (new c)(B(b, c) | B(c, d )) −→ (new c, ack1 )(User1 | (B1 (b, c) | B(c, d )))
cannot be derived. But the reader should be able to infer
τ
User | (new c)(B(b, c) | B(c, d ))−→ (new ack1 )(User1 | (new c)
(B1 (b, c) | B(c, d )))
and this latter process is structurally equivalent to (new c, ack1 )(User1 | (B1 (b, c) |
B(c, d ))).
 2.3 An action semantics for aPi 31
τ
This is a general phenomenon. The internal action relation −→ is able to
mimic reduction, −→, up to structural equivalence. However the proof is not
straightforward. The difficulty lies in the use of the rule (r-struct) in the definition
of reduction, which uses the structural equivalence of Figure 2.3. We need the follow
lemma:
µ µ
Lemma 2.13 If P ≡ Q and P −
→ P  then there exists some Q such that Q −
→ Q
 
such that P ≡ Q .
Proof: Structural equivalence is the smallest equivalence relation that satisfies the
six axioms given in Figure 2.3, and the two (implicit) rules, associated with the
requirement that it is contextual. Now let the relation R be defined by saying P R Q
µ µ
 there exists some Q  such that Q −→Q  , and P  ≡ Q  . Since ≡ is
if whenever P −→P
an equivalence relation it is straightforward to show that R is also an equivalence
relation. Therefore the result will follow, if we show R also satisfies these six
axioms, and the two (implicit) rules. In effect this is a proof by rule induction, as
explained in Chapter 1, on the derivation of P ≡ Q.
As an example we look at the axiom (s-extr); since it is an axiom the induction
hypothesis will not be of any use. One possibility is that P has the form (new n)(P1 |
P2 ) and Q is P1 | (new n) P2 , where n ∈ fn(P1 ). We must show that there is a move
µ
from Q that matches the action P −→ P  . Because of the structure of P there are
only two possible rules that can be used to infer this action:
(l-open): In this case the structure of the label µ must be of the form (n)αo , where αo
is an output label and n must appear in the value being sent. Because of the condition
that n cannot appear in fn(P1 ) we can conclude that the action is performed by P2 .
That is it has the form
(n)αo
(new n)(P1 | P2 ) −−−→ P1 | P2
αo
where P2 −→ P2 . Note that this implies that the bound names in αo do not occur free
in P1 .
We have now accumulated enough information to infer
(n)αo
(new n) P2 −−−→ P2
using (l-open). Then (l-cntx) gives the required matching move
(n)αo
P1 | (new n) P2 −−−→ P1 | P2
in which the residual processes match exactly.
(l-cntx): Here the µ-move must occur within the (new n) − construct and there are
many possibilities for the derivation of this µ-move from P1 |P2 . It may be performed
by P1 alone, by P2 alone, or it may be an internal action in which both participate.
This last possibility is the most interesting and we look at one case, where there is
an output from P2 to P1 . The interest here is that n may form part of the value being
32 The asynchronous PI-CALCULUS

sent, which is freely allowed under the occurrence of (new n) in P, whereas in Q it

would have to be extruded from (new n) P1 to P2 .
τ
So we are in the situation where P −→ P  and P  has the form

(new n) (new b̃)(P1 | P2 )

(b̃)c!V
where P1 − −→ P1 , P2 −
c?V
−−→ P2 . First suppose n is not free in the output label. Then
we can ensure, using α-conversion if necessary, that it does not appear anywhere
(b̃)c!V
in the label and so (l-cntx) can be used to infer (new n) P2 − −−→ (new n) P2 and
(l-comm) then gives the move
τ
P1 | (new n) P2 −→ (new b̃)(P1 | (new n) P2 )
c?V 
We claim that this is a required matching move. For, since n  ∈ fn(P1 ), P1 −
−→ P1 and
we are assuming that n does not appear in the label c?V , we know that n  ∈ fn(P1 ).
Thus (s-extr) (and (s-flip)) can be applied to give

(new n) (new b̃)(P1 | P2 ) ≡ (new b̃)(P1 | (new n) P2 )

On the other hand if n is free in the output label then (l-open) gives
(n)(b̃)c!V
−−−−→ P2 and we get the slightly different move
(new n) P2 −
τ
P1 | (new n) P2 −→ (new n) (new b̃)(P1 | P2 )

which matches exactly.

The symmetric case, when P has the form P1 | (new n) P2 , and Q is (new n)(P1 |
P2 ) is equally delicate. Again a careful analysis of the derivation of the action
µ
P −→ P  is required in order to find the corresponding action from Q. For example
the action could be a communication from (new n) P2 to P1 in which n is exported.
τ
In this case P  will have the form (new n)(P1 |P2 ) and one can show that P1 |P2 −→
P1 | P2 , thereby providing the required move from Q.
This completes our examination of the one axiom (s-extr). Luckily, all the other
axioms are completely straightforward as indeed are the two inductive cases in the
definition of ≡.

τ
Proposition 2.14 P −→ Q implies P −
→ Q for some Q such that Q ≡ Q .
Proof: This is proved by rule induction on the definition of the relation P −→ Q.
τ
In other words we have to show that the relation −→ satisfies all the defining axioms
and rules of −→, given in Figure 2.4.
All the axioms are straightforward and the one explicit inductive rule (s-struct)
is covered by the previous lemma. The implicit inductive rules, present because −→
is defined to be contextual, are also straightforward because of (l-cntx).

The converse is much more straightforward. In fact the reduction relation can
τ
mimic precisely internal actions. However, since P −→ Q is defined in terms of
 2.3 An action semantics for aPi 33
α
the external actions P −→ Q, when giving the proof of this fact we also require
auxiliary properties of these more general actions.
Proposition 2.15
(b̃)c! V

• If P −−−−→ Q then P is structurally equivalent to (new b̃)(c! V

| Q).
−→ Q then P is structurally equivalent to a term of the form (new b̃)(P  | c?(X ) R).
c?V
• If P −
where (b̃) ∩ n(V ) = ∅, and Q is structurally equivalent to (new b̃)(P  | R{|V/X |}).
τ
• P−→ Q implies P −→ Q.

Proof: The proofs of the first two statements are simple rule inductions, on the
(b̃)c!V c?V
inference of the actions P − −−→ Q and P − −→ Q.
The final statement, which is the most interesting, is also by induction on the
τ
inference of P −→ Q. If this is an instance of the axioms (l-eq), (l-neq) or
(l-unwind) then the result is immediate since these axioms are also used in the
definition of reduction. So suppose (l-comm) is used. Without loss of generality
we can assume the internal action has the form
τ
P1 | P2 −→ (new b̃)(P1 | P2 )
c?V  (b̃)c!V 
where P1 − −→P1 and P2 − −−→P2 ; that is P has the form P1 |P2 and Q is (new b̃)(P1 |

P2 ). Here we can use the first two parts of the proposition to give the structure of
the processes involved, up to structural equivalence. We have

P2 ≡ (new b̃)(P2 | c! V
)

and

P1 ≡ (new ñ)(P1 | c?(X ) R)

Moreover, using α-conversion if necessary, we can choose the bound names (ñ)
and (b̃) so that they are different from each other and also different from all the free
names in both P1 and P2 ; this will be useful when manipulating the terms up to
structural equivalence. The second part of this proposition also gives the structure
of the residual P1 :

P1 ≡ (new ñ)(P1 | R{|V/X |})

Therefore using the structural manipulation rules, including (s-extr), we can

rearrange P1 | P2 , the initial process, into the form

(new b̃, ñ)(P1 | P2 | c! V

| c?(X ) R)

This has been constructed so that it can be easily seen to reduce to

(new ñ, b̃)(P1 | P2 | R{|V/X |})

34 The asynchronous PI-CALCULUS

using the reduction rules from Figure 2.4. But, since (ñ) do not occur free in P2 , this
term is structurally equivalent to (new b̃)(P1 | P2 ). So an application of (r-struct)
gives the required
P1 | P2 −→ (new b̃)(P1 | P2 )
τ
There are two more cases to consider in the possible derivations for P −→ Q.
These are the inductive cases, where the instances of the rule (l-cntx) are used.
However they are straightforward and left to the reader.

τ
We can now sum up the relationship between the two relations −→ and −→.
τ
Corollary 2.16 P −→ Q if and only if P −
→ Q for some Q such that Q ≡ Q .

2.4 A coinductive behavioural equivalence for API

At this stage we have an interpretation of aPi as an lts, as given in Definition 1.2:
• The states or configurations are all aPi processes, that is all the closed terms in aPi.
µ
• The relations over the configurations are given by the actions −→, the least relations that
can be deduced from inference rules in Figure 2.5.

This is turn means that we have a bisimulation equivalence, denoted P ≈bis Q,

between aPi processes. However we must be a little careful in applying the general
definition to this lts generated by aPi, because of the use of bound variables in
(b)c!b
actions. For example if P −−−→ P  where b has a free occurrence in Q then we
(b)c!b
would not expect Q to be able to perform an exact matching move Q ===⇒ Q .
Instead we apply Barendregt’s convention, which dictates that this action should
not be considered as b is not fresh to its context, since it appears free in Q. Thus
the convention dictates that when the definition of bisimulation is applied to the
processes P, Q, only actions whose bound names do not occur freely in P and Q
are expected to be matched.
We have already discussed in Chapter 1 the attractiveness of this semantic
equivalence. For example to show that two processes are equivalent it is sufficient
to exhibit a bisimulation containing them. In fact Lemma 2.13 provides us with a
method of working with bisimulations up to structural equivalence. First a simple
consequence:
Corollary 2.17 In aPi, P ≡ Q implies P ≈bis Q.

Proof: Since ≡ is symmetric, Lemma 2.13 immediately implies that ≡ is a weak

bisimulation, and the result therefore follows from the definition of ≈bis , as the
largest bisimulation.

 2.4 A coinductive behavioural equivalence for aPi 35

Definition 2.18 (bisimulation equivalence up to structural equivalence) A relation

R over processes is called a bisimulation up to structural equivalence if both it and
its inverse satisfies the transfer property:

In other words when matching the residuals of actions it is sufficient to work up to

structural equivalence.
Proposition 2.19 If P R Q, where R is a bisimulation up to structural equivalence,
then P ≈bis Q.
Proof: The result will follow if we can show that the relation ≡ ◦ R ◦ ≡, which
we abbreviate to S , is a bisimulation since trivially the identity relation is contained
in ≡ and therefore R ⊆ S .
µ
So suppose P S Q and P −→ P  ; we must find a matching move from Q. Let
P1 , Q1 be such that
P ≡ P1 R Q1 ≡ Q
µ
Using Lemma 2.13 we can find a move P1 −→ P1 such that P  ≡ P1 . Using the
µ̂
supposed transfer property of R we can find a move Q1 =⇒ Q1 such that P1 S Q1 .
µ̂
Again using Lemma 2.13, possibly a number of times, we can find a move Q =⇒ Q
 
such that Q1 ≡ Q . This is in fact the required matching move since we have
P  ≡ P1 S Q1 ≡ Q
from which it follows that P  S Q .
We also have to show that S −1 satisfies the transfer property; however the proof
is practically identical to that for S .

Bisimulation equivalence also interacts coherently with the operators of aPi;

they are contextual. Here we outline the proof of two results that, together, show
that it is contextual.
Proposition 2.20 In aPi, P ≈bis Q implies (new n) P ≈bis (new n) Q.
Proof: Let S be the set of all pairs (new n) P1 , (new n) P2
such that P1 ≈bis P2
and let R be S ∪ ≈bis . The result follows if we can show that R is a bisimulation.
This however is not very difficult as every action from (new n) P is determined by
an action from P.
36 The asynchronous PI-CALCULUS

Note however that R must include ≈bis . This is because processes of the
form (new n) R may extrude n as part of an output action. For example one
(n)αo
possible action from (new n) P1 is (new n) P1 −−−→ P1 , where αo is an output
αo
action P1 −→ P1 . This latter can be matched by a partner process, one such that
(new n) P1 S (new n) P2 , because P1 ≈bis P2 . Because of this equivalence there is
αˆo
an action P2 =⇒ P2 such that P1 ≈bis P2 ; this in turn can be transformed into an
(n)αˆo
action matching the original one from (new n) P1 , (new n) P2 ==⇒ P2 . But note
that the resulting pair P1 , P2
is not in S ; however it is in R, which is all that is
required for the proof to go through.

Proposition 2.21 In aPi, P1 ≈bis P2 implies P1 | Q ≈bis P2 | Q.

Proof: This proof is somewhat more complicated. The relation consisting of all
pairs of the form P1 |Q, P2 |Q
such that P1 ≈bis P2 is not in general a bisimulation.
We have to construct a more sophisticated one. Let R be the least relation that
satisfies
• P1 ≈bis P2 implies P1 , P2
∈ R
• P1 , P2
∈ R implies P1 | Q, P2 | Q
∈ R for every process Q
• P1 , P2
∈ R implies (new n) P1 , (new n) P2
∈ R for every name n.

We show R is a bisimulation from which the result will follow because of the
second clause. Note that by definition R is symmetric and therefore we need only
prove the transfer property in one direction.
µ
Let P, Q
∈ R and P −→ P  . We must find a matching move from Q, a move
µ̂   
Q =⇒ Q such that P , Q
∈ R. How we find this matching move depends on the
structure of P and Q. To discover this structure we do an induction on the proof
that the pair is in R. There are three possibilities:
• P, Q
∈ R because P ≈bis Q. The fact that ≈bis is a bisimulation immediately gives the
required matching move.
• P, Q have the form P1 | Q , P2 | Q , respectively, and P1 , P2
∈ R. Here induction will
ensure that every move from P1 can be matched by a move from P2 .
µ
The proof proceeds by rule induction on the derivation of the action P −→ P  . There are
numerous cases and we only examine one, when µ is τ because of an output from P1 to
Q . So we have actions
(b̃)αo αi
P1 −−−→ P1 Q −→ Q
where P  is (new b̃)(P1 | Q ); here αo is some simple output action a!V and αi the
complementary input action a?V .
(b̃)αo
Induction now gives a matching move from P2 , an action P2 ===⇒ P2 such that
P1 , P2
∈ R. We can combine this matching move with the complementary action
τ ∗
from Q to give Q −→ (new b̃)(P2 | Q ). This is the required matching move; the
second, and more particularly the third, clause in the definition of R, ensures that
P  , (new b̃)(P2 | Q )
∈ R.
 2.5 Contextual equivalences 37

• The final possibility is handled in a similar manner. Here P, Q have the form (new n) P1
and (new n) P2 , respectively, for some n, and P1 , P2
∈ R. The move from P is
determined by a move from P1 , induction gives a matching move from P2 , which in
turn gives the required matching move from Q.

Thus the equivalence relation ≈bis is contextual; an argument completely

symmetric to that of Proposition 2.21 will show P1 ≈bis P2 implies Q |P1 ≈bis Q |P2 .
With some more work we could also prove that it is also preserved by the other
constructs in the language. But the static operators are sufficient for our purposes.

2.5 Contextual equivalences

We have seen that ≈bis is an excellent behavioural equivalence for aPi:
• it is bisimulation based, and therefore has associated with it powerful coinductive proof
techniques
• it is contextual, and therefore appropriate for a compositional approach to process
verification.

In this section we step back and examine the extent to which it is the most appropriate
semantic equivalence for aPi, despite these favourable properties.
From the most general point of view, processes should only be considered to
be semantically different if a user can observe a difference in their behaviour.
The difficulty is in formalising how users interact with processes and how they
can come to discern differences. In aPi users can only interact with processes
by communicating on channels, and these interactions form the basis of the
definition of ≈bis . Consequently we would expect that bisimulation equivalence
will imply whatever semantic equivalence based on user interaction that emerges.
Nevertheless, there is still room for discussion on what this more basic notion of
equivalence should be.
As a first attempt we could say that two processes are distinguishable only if
there is some action that one can perform and the other cannot; a priori a user
could then discern a difference by asking for this action to be performed. But this
is easily seen to be much too weak a notion. Defined in the following manner P1
and Q1 would be considered to be semantically equivalent, as they both offer the
same interaction on channel a:

P1 ⇐ (new n)(a! n
| n?b!) Q1 ⇐ (new n)(a! n
| n?c!) (2.6)

But they obviously should be considered semantically different and the difference
can be discerned by subsequent interaction. An observer that inputs on the channel
received on a, will receive either a or b, depending on whether they are observing P1
38 The asynchronous PI-CALCULUS

or Q1 . In other words our semantic equivalence should take into account repeated,
or more complex, methods for interacting with, or observing processes.
The literature is littered with various attempts at formalising what it means to
observe processes, many of which are difficult to justify. Here we take a different
approach; we define our semantic equivalence in terms of desirable, and reasonable,
properties we would like it to enjoy. The approach is straightforward. We list
desirable properties P1 , . . . , . . . , Pn and define our semantic equivalence to be the
largest equivalence relation between processes that satisfies all of them. In other
words processes will be distinguished only if it is required by one of our desirable
properties.
The first property is purely observational:
(b̃)c!V
Definition 2.22 (observations) Let P ⇓barb c if P ===⇒ P  , for some P  , (b̃) and
value V .
We say a relation R over processes preserves observations if

P, Q
∈ R implies P ⇓barb c if and only if Q ⇓barb c

for every name c. 

This notion of observation is easy to justify. We can design a simple test that will
determine if a process can perform such an observation. For example let Cc [−] be
the context given by
[−] |c?(x)eureka!
(b̃)c!v
Then the overall system Cc [P] will be able to report eureka if and only if P ===⇒P  ,
for some P  , for some simple value v.
Nevertheless we have already seen that this property alone is not sufficient to
determine a good semantic equivalence; for example P1 and Q1 defined above in
(2.6) would not be distinguished.
Another desirable property is preservation by contexts; as we have already
mentioned this means that the equivalence could be used in the compositional
construction and analysis of systems. To keep life simple we will concentrate on
static contexts. So as a second attempt we could use these two properties:

Definition 2.23 (a contextual equivalence) Let  be the largest equivalence relation

over processes that
• preserves observations
• is contextual. 
 2.5 Contextual equivalences 39

This is a considerable improvement on our first attempt. For example, this satisfies
the property

P  Q implies C[P]  C[Q]

for any static context C[ ]. Indeed this property enables us to show that P1   Q1 ,
where these processes are defined in (2.6). To see this it is sufficient to observe them
in a static context, which examines the further actions they perform. Let Cab [−] be
the context

[−] |a?(x) x! | b?eureka!

Then Cab [P1 ] ⇓barb eureka whereas Cab [Q1 ] ⇓barb eureka. Consequently
Cab [P1 ]  Cab [Q1 ], and therefore P  Q.
This is the standard method for showing that two processes are not related via ;
find a static context and an observation that will distinguish them when placed in that
context. But proving that two processes are equivalent is far less straightforward.
In the following example we use

P⊕Q (2.7)

as an abbreviation for

(new n)(n! | n?P | n?Q)

where n is chosen so that it does not occur in either of P, Q. This is called the
internal choice between P and Q because it may non-deterministically choose to
execute either of these processes. Consider

P2 ⇐ b?c! Q2 ⇐ b?c! ⊕ stop (2.8)

P2 can output on c after having received an input on b. Q2 also has this behaviour
but it may, in addition, evolve into the deadlocked state stop; in other words Q2
may (randomly) decide either to act like P2 , or become deadlocked. It turns out that
P2  Q2 but how do we prove it?
We could construct a relation R that
• contains the pair P2 , Q2

• is contextual
• preserves observations.

Since  is the largest relation with the last two properties it will follow that
R ⊆  and therefore that P2  Q2 . However constructing such as R turns
40 The asynchronous PI-CALCULUS

out to be a non-trivial task. The obvious candidate R1 , given (up to structural

congruence) by
P2 ←→ Q2
c!
←→ c!
| (new n)(n? stop)
stop ←→ (new n)(n? stop)
is not contextual. We could force it to be contextual, by considering the least relation
R2 that contains R1 and is closed under static contexts. But is R2 now closed under
observations?
It turns out that this is indeed true although the proof is not straightforward. But
it does emphasise that although our approach to defining semantic equivalences
may be reasonable, in general it leads to relations that are very difficult to handle
mathematically.
Nevertheless this example also shows that  must be rejected as a behavioural
equivalence, as it does not detect possible deadlocks in processes. Although the
deadlock in question is internal to Q2 its existence will have an effect on observers
of the system. For example if Q is the process b! | c? print! then (P2 | Q ) will
always result in a print, whereas (Q2 | Q ) may become deadlocked, depending on
the internal choice made by Q2 .
The more basic problem with  is that it does not take into account in any way the
internal branching structure of processes; Q2 has a primitive branching structure
not present in P2 , and one of the possible choices leads to problematic behaviour
not present in P2 . So we must add to our list of desirable properties something that
will take this internal branching structure of processes into account. There is no
obvious candidate and here we rely on a reduced version of bisimulation, which
demands that the internal reductions of related processes should in turn be related.
This property is very discerning and it is probably the most refined manner in which
one might want to distinguish the internal potential branchings of processes.
Definition 2.24 (reduction-closure) The relation R over processes is said to be
reduction-closed if, whenever S is either R or its inverse R−1 , it satisfies the
transfer property:
 2.5 Contextual equivalences 41

Formally we require that if P, Q

∈ R and P −→ P  then there exists some
process Q such that Q −→∗ Q and P  , Q
∈ R, and similarly for reductions
from Q. 

We add this to our list of desirable properties, to give us our third, and final property
based semantic equivalence:

Definition 2.25 (reduction barbed congruence) Let =

∼ be the largest relation over
processes that
• preserves observations
• is contextual
• is reduction-closed. 

Proposition 2.26 The relation =

∼ is an equivalence relation.
Proof: See Question 3 at the end of the chapter.

With this new equivalence we can distinguish between the processes P2 , Q2

defined above in (2.8). We can prove that if R is any equivalence relation that has
these desirable properties it is not possible for it to contain the pair P2 , Q2
. For if
it did, it would also have to contain the pair Cbc [P2 ], Cbc [Q2 ]
, where Cbc [−] is
the context [−] | b! | c?eureka!. But since R is reduction-closed and Cbc [Q2 ] −→
Q , where Q is the deadlocked process Cbc [stop], this would require a reduction
Cbc [P2 ] −→∗ Q for some Q such that Q , Q
∈ R. But it is straightforward to
see that Q ⇓barb eureka for all Q such that Cbc [P2 ] −→∗ Q ; there are in fact
only three possibilities, up to structural equivalence, Cbc [P2 ] itself, c! | c?eureka!
and eureka!. Now, since R preserves observations, this would require Q ⇓barb
eureka, which is obviously not true.
We take = ∼ to be our touchstone equivalence, motivated by a minimal set of
desirable properties one might require of a semantic equivalence. The reasoning
just carried out provides a general strategy, based on these properties, for showing
that two processes are not equivalent. It is also possible to use the definition of = ∼
in order to develop properties of it. For example structural equivalence has its
three defining properties, that is, it is contextual, reduction-closed and preserves
observations. Since = ∼ is the largest such relation it follows that P ≡ Q implies
P= ∼ Q.
However, as we have already demonstrated with , this form of definition often
makes it difficult to show that a pair of processes are equivalent. In general it
is necessary to construct a relation containing them that has the three defining
properties, something that is not always easy. Another trivial example emphasises
the point.
42 The asynchronous PI-CALCULUS

Example 2.27 Let P3 , Q3 be the processes

(b! ⊕ b!) b!
respectively, where the internal choice operator ⊕ is defined in (2.7) above. To
show P3 =∼ Q3 we need to construct a relation R that contains the pair P3 , Q3
and
has the three desirable properties. The obvious candidate
R1 = { P3 , Q3
} ∪ Id
where Id is the identity relation, is reduction-closed (trivially) but fails to be
contextual. Another possibility would be to let R2 be the closure of R1 under
static contexts, as in the proof of Proposition 2.21. But now one has to show that
R2 is reduction-closed. This involves an inductive proof on the inductive closure,
together with an analysis of b residuals of processes. The argument is not involved
but it does seem overly complicated for such a simple pair of processes.

This provides a good raison d’être for bisimulation equivalence:
Proposition 2.28 P ≈bis Q implies P =
∼ Q.
Proof: From Proposition 2.21 and Proposition 2.20 we know that ≈bis is contextual
and it obviously preserves observations. Let us prove that it is also reduction-closed.
Suppose P ≈bis Q and P −→ P  ; we must find a matching move Q −→∗ Q .
τ
By Proposition 2.14 we know P −→ P  for some P  such that P  ≡ P  . We can
τ ∗ 
therefore find a derivation Q −→ Q for some Q such that P  ≈bis Q . Applying
Proposition 2.15, we know Q −→∗ Q and this is the required matching move;
since ≡ is contained in ≈bis (see Corollary 2.17), it follows that P  ≈bis Q .
So bisimulation equivalence has all the defining properties of =. ∼ Since = ∼ is the
largest such equivalence it follows that ≈bis ⊆ =. ∼

Thus bisimulation equivalence may be viewed as providing a convenient

methodology for proving processes semantically equivalent. For example to show
P3 and Q3 , from Example 2.27 are equivalent, it is sufficient to show that R1
is a bisimulation (up to structural equivalence), a simple task. Essentially we are
replacing the need to analyse R2 , the closure of R1 under static contexts, with an
analysis of R1 with respect to arbitrary actions.
Can we always use this proof method to demonstrate the equivalence of
processes? The answer is no.
Example 2.29 It is trivial to see that c?c! ≈bis stop but it turns out that c?c! =
∼ stop.
To see this let R denote the set of all pairs P1 , P2
such that
P1 ≡ (new ñ)(P | c?c!)
P2 ≡ (new ñ) P
 2.6 An observational lts for aPi 43

for some P. It is possible to show that R satisfies the defining properties of =; ∼

Corollary 2.16 is useful in proving that it is reduction-closed. Then since R contains
the pair c?c!, stop
it follows that c?c! =
∼ stop.

Intuitively the reason for not being able to distinguish between c?c! and stop is
that, regardless of the context in which these are placed, it is difficult to conceive
of an observation that can distinguish them. One can send a message along c to the
former, but since output is asynchronous, that is no behaviour can depend on its
receipt, an observation can also not depend on it. Another more general example is
given by
c?(x) (c! x
| c?(x) R) =
∼ c?(x) R
Bisimulation equivalence is defined in terms of the ability of processes to perform
input and output actions whereas = ∼ is defined on the ability of contexts to
observe these actions. Thus Proposition 2.28 is understandable; but underlying
these counter-examples to the converse implication is the fact that certain actions
cannot be observed.

2.6 An observational lts for API

Here we take as basic the reduction semantics of Section 2.2 and discuss the extent
to which observers can see the actions being performed by processes.
Consider the context Cout [−] given by the term
[−] |c?(x) R
Placing the process P in this context may be viewed as testing if P can output a
simple value on the channel c. Indeed if we define the residual R to be the term
if x = n then eureka! else stop
for a particular name n, then we can determine if P can output n on c. For the testing
harness
Cout [P]
will be able to report eureka if and only if P can output the name n on the channel
c. Consequently, we can give a stronger interpretation to the judgement
c!n
P −→ Q
taking it to mean
• the process P has the ability to output the value n on c, thereby being transformed into Q
• moreover the surrounding environment can observe that P has indeed performed the
output of n along c.
44 The asynchronous PI-CALCULUS

Figure 2.6 Asynchronous input rules for aPi

Turning to input, the situation is quite different. How can we determine if a

process has actually input n on c ? The context Cin [−] defined by
[−] |(c! n
| eureka! )
is certainly not good enough, as Cin [P] can report eureka regardless of the
properties of P. In fact it is not possible to come up with a context Cin [−] with the
property that P inputs n on c if and only if Cin [P] can report eureka.
So if we wish to define relations that represent the manner in which a user can
c?V
observe a process, we have to replace P − −→ Q with a weaker relation; we have to
weaken the input rules used in Figure 2.5.
c?V
Let P − −→a Q be the least relation satisfying the rules given in Figure 2.6. The
c?V
first rule (a-con), also used for P − −→ Q, now represents the fact that when V is
made available for input along c then the proffered value may be consumed by a
process of the form c?(X ) P. However since the observer, providing the input, has
no way of confirming its reception, it is also possible that the offered value remains
unconsumed. Thus we also allow the rule (a-del)
c?V
P−
−→a P | c! V

for any process P. Intuitively this means that, when an observer proffers the value
V along c, the value may just remain there waiting for the process to consume
it; the value is delivered to the process P, but it awaits consumption. The final
rules are borrowed directly from Figure 2.5 and simply allow the axioms to occur
appropriately under static contexts.
The properties of the new asynchronous input action are very close to those of
the standard (synchronous) version:
Lemma 2.30
• P− −→ P  implies P −−→a P  .
c?V c?V
(b̃)c!V τ ∗
• P1 −−→a P1 and P2 −
c?V
−−→ P2 implies P1 | P2 −
→ Q for some Q structurally equivalent
to (new b̃)(P1 | P2 ).
 2.6 An observational lts for aPi 45

Proof: The proof of the first statement is straightforward, as all the defining rules
for P −−→ P  are included in those of P −
c?V
−→a P  .
c?V

The second is proved by induction on why P1 − −→a P1 . If this is inferred

c?V

by the axiom (a-con) the result is immediate since we have P1 − −→ P1 . The
c?V

non-trivial case is when it is inferred by the axiom (a-delv). In this case P1 is
P1 | c! V
and from Proposition 2.15 we know P2 is structurally equivalent to
(new b̃)(c! V
|P2 ). So, via applications of (s-extr), (new b̃)(P1 |P2 ) is structurally
equivalent to P1 |P2 ; the bound variables can be chosen fresh to P1 . And so trivially,
τ ∗
up to structural equivalence, P1 | P2 −→ (new b̃)(P1 | P2 ), in zero steps.
c?V 
The inductive cases, when P1 −−→a P1 is inferred by the rules in (a-cntx), are
routine. For example suppose P1 , P1 have the form (new d ) P, (new d ) P  , where
P− −→a P  ; let us choose the bound name d so that it is new to P2 . Then by induction
c?V

we have
τ ∗ 
P | P2 −→ Q
such that Q ≡ (new b̃)(P  | P2 ). An application of (l-cntx) gives
τ ∗
(new d )(P | P2 ) −→ (new d ) Q
Note that P1 | P2 is structurally equivalent to (new d )(P | P2 ) and therefore an
application of Lemma 2.13 then gives
τ ∗
P1 | P2 −→ Q
for some Q ≡ (new d ) Q . This is the required matching move, because, since d is
chosen to be fresh, we have (new d ) Q ≡ (new b̃)(P1 | P2 ).

With these inference rules we now have a new interpretation of aPi as an lts:
• the configurations are, as before, the closed terms in aPi
• the relations over the configurations are given by the actions

c?V
– P− −→a Q
(b̃)c!V
– P −−−→ Q
τ
– P −→ Q.

We refer to this as the asynchronous lts for aPi, or the asynchronous interpretation
of aPi. For notational convenience an arbitrary action in this lts will be denoted
µ 
by P −→ a P , although for output and internal actions this will coincide with the
µ
standard actions P −→ P  . In particular, it is worth remembering that the internal
τ
action P −→a P is still defined in terms of the standard (synchronous) input and
output actions.
Definition 2.31 (asynchronous bisimulations for aPi) Any relation that satisfies
the transfer properties in the asynchronous lts for aPi is called an asynchronous
46 The asynchronous PI-CALCULUS

bisimulation. Let P ≈a Q denote the corresponding weak bisimulation equivalence.

We refer to this relation as asynchronous bisimilarity. 
This new semantic equivalence enjoys many of the properties of that defined
in Section 2.4. For example it is straightforward to adapt Definition 2.18, to
asynchronous bisimulations, to obtain asynchronous bisimulations up to structural
equivalence, and we have the following adaptation of Proposition 2.19:
Proposition 2.32 If P R Q, where R is an asynchronous bisimulation up to
structural equivalence, then P ≈a Q.
Proof: The proof is very similar to that of Proposition 2.19. However we need to
generalise Lemma 2.13 to the asynchronous actions. We need to show that if P ≡ Q
and P − −→a P  then there exists some Q such that Q −
c?V
−→a Q such that P  ≡ Q .
c?V

−→a P  ; See
c?V
This is straightforward by induction on the derivation of the action P −
Question 5 at the end of the chapter.
With this result the proof now follows as in Proposition 2.19.

Example 2.33 Here we show that c?c! ≈a stop.

Let R be the least relation that satisfies
(i) stop R stop
(ii) c?c! R stop
(iii) P R Q implies P | d ! V
R Q | d ! V
for every name d and value V .

We show that R is an asynchronous bisimulation up to structural induction, from

which it will follow that c?c! ≈a stop. Because of the novelty of asynchronous
actions it is worthwhile going into some detail here.
µ 
Suppose P R Q and P −→ a P ; we must find a matching move from Q. This is
found by induction on the proof that P R Q. There are three cases. The first, when
both P and Q are stop is vacuously true.
The second is when P is c?c! and Q is again stop. Here there are two possible
c? c?
moves from P, namely P −→ a c! and P −→ a c?c! | c!. Both are matched, up to
c?
structural induction, by the asynchronous action Q −→ a stop |c!. For example, to
see the first match note that c! ≡ stop |c!, and therefore by (i), followed by an
instance of (iii) we have stop |c! R stop |c!.
The third is when P, Q have the form P  | d ! V
, Q | d ! V
, respectively, and
we know P  R Q . Here there are numerous possibilities for the move from P. If
it is performed by P  we may use induction to find the corresponding move from
Q and therefore from Q. If it is performed by the right component d ! V
then it
is straightforward. The only remaining possibility is a communication between P 
τ
and this component, namely P  | d ! V
−→ 
a P | stop because P −
 d−
→ P  .
?V
 d ?V 
By the first part of Lemma 2.30 we know P −−→a P , which has, by induction, a
matching move Q − −→a Q ; the second part of the same lemma gives the required
d ?V
 2.7 Justifying bisimulation equivalence contextually 47
τ ∗ 
matching move from Q, namely Q −→ a Q | stop.
Incidentally it is possible to show that in this case d must be c and the value V the
empty pattern. But this is not actually needed in the proof.
We also have to show the corresponding result for Q; that is if P R Q then
every move from Q can be matched by a move from Q. Fortunately, because of the
manner in which R is defined, this is straightforward.

This example demonstrates that constructing asynchronous bisimulations is not

quite as easy as standard bisimulations; one must always take into account possible
input moves generated by the rule (a-delv). Nevertheless they are much easier to
handle than contextual relations. Moreover there are slightly easier formulations, at
the expense of changing the definition of bisimulation; see Question 16. However
it is also possible to show that ≈bis ⊆ ≈a (see Question 12), which in turn means
that we can also demonstrate that P ≈bis Q by exhibiting a (standard) bisimulation
R that contains the pair (P, Q).
However asynchronous bisimulations have the advantage of providing a
complete proof methodology for =; ∼ if P =∼ Q then there is an asynchronous
bisimulation that relates them. This is the topic of the next section.

2.7 Justifying bisimulation equivalence contextually

First let us show that ≈a satisfies all the desirable properties that are used to define =.
∼
Since ≈a is itself an asynchronous bisimulation, it is obviously reduction-closed;
it is also straightforward to prove that it preserves observations.
Proposition 2.34 The relation ≈a is contextual.
Proof: We use a slight adjustment to the proof of of Proposition 2.21. Let R be the
least relation containing ≈a , with the property that if P1 , P2
∈ R then

• P1 | Q, P2 | Q
∈ R for every process Q
• (new n) P1 , (new n) P2
∈ R for every name n.

We prove that R is a weak bisimulation up to structural equivalence. From this it

will follow that ≈a is preserved by both parallel and name binding contexts.
As in the proof of Proposition 2.21 it is sufficient to show that whenever
µ  µ̂ 
P, Q
∈ R every move P −→ a P has a matching move Q = ⇒ a Q . The proof
proceeds by induction on why P, Q
∈ R, but here the matching is up to structural
equivalence. Most cases are identical. There is only one complication, when µ = τ
and the move is an internal communication. Here P, Q are of the form P1 |Q , P2 |Q
and we know by induction that P1 , P2
∈ R. Suppose the move we are trying to
τ (b̃)c!V
match is P1 | Q −→ (new b̃)(P1 | Q ) because P1 −
−→ P1 and Q −
c?V
−−→ Q .
48 The asynchronous PI-CALCULUS

Here we employ Lemma 2.30. Using the first part we know P1 − −→a P1 and
c?V
c?V 
therefore by induction this can be matched by a move P2 ==⇒a P2 . Now employing
the second part of the same lemma we have, up to structural induction, a required
τ ∗
matching move P2 | Q −→ (new b̃)(P2 | Q ).

Corollary 2.35 If P ≈a Q then P =

∼ Q.
Proof: Follows from the fact that ≈a has all the defining properties of =.
∼

Thus asynchronous bisimulation equivalence is as least as good as the standard

version, in that it provides a proof method for establishing that processes are
reduction barbed congruent. The key to the converse of this result is the fact
that for every asynchronous action there is a specific context, or test, which can
observe it. We have already alluded informally to these contexts in the discussion
of Section 2.6.
Definition 2.36 (definability of actions) We say the external action α (in the
asynchronous lts) is definable if for every finite set of names N , and every pair
of actions names succ, fail, not contained in N , there is a testing process
T (N , succ, fail, α) with the property that, for every process P such that fn(P) ⊆ N ,
α
• P −→a P  implies that T (N , succ, fail, α) | P −→∗ (new bn(α))(succ! bn(α)
| P  )
• T (N , succ, fail, α) | P −→∗ Q , where Q ⇓barb succ, Q  ⇓barb fail, implies that
α
Q ≡ (new bn(α))(succ! bn(α)
| P  ) for some P  such that P =⇒ 
a P . 

Note that there is a subtlety here with the bound names in actions; these can only
occur in output actions. The tests cannot provoke exactly the same reaction from a
(b)c! a,b

process P as these actions. For example if P − −−−−→a P  then running P in parallel

with the associated test T (N , succ, fail, α) will not result in succ! | P  but only in
the more restricted term (new b)(succ! b
| P  ), in which the subsequent behaviour
on b is not immediately available.
Theorem 2.37 (actions are definable) Every external action in the asynchronous
lts of aPi is definable.
Proof: The input case is now straightforward, because of asynchrony. If α is c? V
,
in which case bn(α) is empty, let T (N , succ, fail, α) be the term
c! V
| succ!
which does not use fail; for convenience we abbreviate this to T . Then a simple
proof, by induction on why P − −→a P  , will show that, up to structural equivalence,
c?V
τ ∗
T |P −→ succ!|P . It follows from the third part of Proposition 2.15 that T |P −→∗


succ! | P  .
τ ∗
To prove the converse first suppose T | P −→ Q. It is easy to see that Q has
τ α

either the form T | P where P −→ P or it has the form succ! | P  where P =⇒
∗  P.
 2.7 Justifying bisimulation equivalence contextually 49

But in either case Q may be written, up to structural equivalence, as succ! | P 

α 
where P =⇒ a P , because of the first part of Lemma 2.30. Therefore, again by
Corollary 2.16, if T | P −→∗ Q, where Q ⇓barb succ, then Q must be structurally
α
equivalent to a term of the form succ! | P  , where P =⇒ 
a P .
In the output case, when α has the form (b̃)c!V , we have already given the
essential idea of the context in the discussion in Section 2.3. The precise details
are quite complicated because in aPi we have allowed values V to be tuples of
simple values. We will give the proof of the case when α = (b)c!(b, v); from this
it should be clear that a proof can also be constructed in the more general case, for
an arbitrary V .
Here T (N , succ, fail, α), which again we abbreviate to T , has the structure
fail! | c?(x, y) Q
where Q tests the incoming values to ensure
• the value bound to y is v
• that bound to x is a new channel.

The first requirement is easy to code using a construct of the form

if x = v then Q else stop. We also know that a channel is new if it is different
from all the names in N , which by the hypothesis includes all those occurring free
in the processes we are testing. So our context takes the form
fail! | c?(x, y)if y = v then
if x ∈ N then stop
else fail? succ! x
else stop
where if y ∈ N then P else P  is an abbreviation for the obvious sequence of
nested tests for equality for membership of N .
We leave the reader to check the requirements in this case; because of
Corollary 2.16 these may be simplified to:
α τ
• P −→ P  implies T | P −→∗ Q for some Q structurally equivalent to (new b)(succ! b
| P  )
τ
• T | P −→∗ Q, where Q ⇓barb succ and Q  ⇓barb fail implies Q is structurally equivalent
α
to (new b)(succ! b
| P  , where P =⇒ P.

Note that the use of fail in the test ensures that if Q  ⇓barb fail then the process
being tested has to have performed the output action.

The next lemma enables us to recover the full use of the residuals obtained
by using these tests to provoke actions, essentially stripping off the bound names
inherited from output actions.
50 The asynchronous PI-CALCULUS

Lemma 2.38 (extrusion) Suppose (ñ) ⊆ (m̃), where both are sequences of distinct
names.
Then (new ñ) (P | succ! m̃
) =
∼ (new ñ) (Q | succ! m̃
) implies P =
∼ Q, provided
succ is fresh.
Proof: We define a relation R by letting P R Q if there is some succ fresh to P
and Q and some (ñ) ⊆ (m̃) such that

(new ñ)(P | succ! m̃

) =
∼ (new ñ)(Q | succ! m̃
) (2.9)

The result follows if we can show that R satisfies the defining properties of =.
∼ Note
that because of Question 10, the actual fresh name used here, succ, is not actually
important; for if succ is another fresh name then (2.9) also implies, by applying
an injective substitution, that

(new ñ)(P | succ ! m̃

) = 
∼ (new ñ)(Q | succ ! m̃
)
The freshness of succ ensures that R is obviously reduction-closed. Let us see
why it also preserves observations. So suppose P ⇓barb b where P R Q, that is

(new ñ)(P | succ! m̃

) =
∼ (new ñ)(Q | succ! m̃
)
for some (ñ) ⊆ (m̃). We have to show Q ⇓barb b.
If b does not occur in (ñ) then this is obvious, since (new ñ)(P | succ! m̃
) ⇓barb
b. So suppose it does. We no longer have (new ñ)(P | succ! m̃
) ⇓barb b but b can
be extruded via succ. Suppose b is the ith element in the list (m̃). Then let T denote
the process

succ?(X ) xi ?eureka!

where eureka is some fresh name, and the pattern X is chosen to match (m̃). Then
because P ⇓barb b we also have

T | (new ñ)(P | succ! m̃

) ⇓barb eureka

Since

T | (new ñ)(P | succ! m̃

) =
∼ T | (new ñ)(Q | succ! m̃
)
it must be that

T | (new ñ)(Q | succ! m̃

) ⇓barb eureka

But this is only possible if Q ⇓barb b.

Now let us show that R is contextual. As an example we show that it is preserved
by parallel contexts; the case of name binding is even simpler.
 2.7 Justifying bisimulation equivalence contextually 51

Assuming P1 R P2 we have to show that (P1 | Q) R (P2 | Q) for an arbitrary

process Q; that is
(new ñ)(P1 | Q | succ ! m̃
) = 
∼ (new ñ)(P2 | Q | succ ! m̃
) (2.10)
for some (ñ) ⊆ (m̃), and for some name succ fresh to P1 , P2 , Q and (m̃). We
know that for some succ not occurring in P1 , P2 and (m̃),
(new ñ)(P1 | succ! m̃
) =
∼ (new ñ)(P2 | succ! m̃
) (2.11)
for some (ñ) ⊆ (m̃). A priori succ may occur in Q; but Question 10 may be applied
to ensure that this is not the case. However some names in (ñ) may be used in Q,
which precludes the straightforward application of (2.11) to achieve (2.10).
However we may proceed as above, when proving that R preserves observations.
Let X be a pattern that matches m̃, and QX an open term such that QX {|m̃/X |} evaluates
to the process Q; it is obtained by replacing each occurrence of mi in Q by xi . Then
(2.11) implies
(new succ)((new ñ)(P1 | succ! m̃
) | O) =
∼ (new succ)((new ñ)
(P2 | succ! m̃
) | O)
where O is the process
succ?(X ) (QX | succ ! X
)
This takes all the values in V , including those scoped by (ñ), and makes then
available both to Q and on the new fresh channel succ . However it is easy to
check that
(new succ)((new ñ)(P | succ! m̃
) | O) ≈bis (new ñ)(P | Q | succ ! m̃
)
for any process P, by constructing an explicit bisimulation. The required result,
(2.10), now follows by Proposition 2.28.

We are now ready to prove that asynchronous bisimulation equivalence completely

characterises our touchstone equivalence:
Theorem 2.39 (full-abstraction) P1 ≈a P2 if and only if P1 =
∼ P2 .
Proof: We already know, from Corollary 2.35, that ≈a ⊆ =. ∼ So the result will
follow if we can show that = ∼ is an asynchronous bisimulation, up to structural
equivalence.
µ 
So suppose P1 = ∼ P2 and P1 −→a P1 . We must find a matching weak move from
P2 . If µ is τ we obtain it from the fact that =
∼ is reduction-closed. So let us assume
that it is an external action α. We now use the test for α given by the definability
result, choosing N to contain all the free names in both P1 and P2 and choosing
succ and fail to be fresh to both P1 and P2 ; for convenience we denote it by T .
52 The asynchronous PI-CALCULUS

Because =
∼ is contextual we know that
T | P1 =
∼ T | P2
We also know that
T | P1 −→∗ (new bn(α))(succ! bn(α)
| P1 )
and therefore T | P2 −→∗ Q for some Q such that
(new bn(α))(succ! bn(α)
| P1 ) =
∼Q
This means that Q ⇓barb succ and Q ⇓barb fail and so the second part of definability
gives that Q is structurally equivalent to some process (new bn(α))(succ! bn(α)
|
α
P2 ), where P2 =⇒ 
a P2 . Since structural equivalence is contained in = we know
∼
(new bn(α))(succ! bn(α)
| P1 ) = 
∼ (new bn(α))(succ! bn(α)
| P2 )
to which the extrusion lemma can be applied to obtain the required P1 = 
∼ P2 .

This completes our exposition of our version of the pi-calculus, aPi. The
primary semantics of the language is expressed as a reduction semantics, which
describes how in principle processes perform computations. This reduction
semantics is in turn the main ingredient in the behavioural equivalence between
processes, =,
∼ which is designed to capture how processes behave as components in
larger systems. We then established that bisimulations provide a proof methodology
for establishing such behavioural equivalences. Finally we showed how the
definition of bisimulations could be adjusted, so that the result, asynchronous
bisimulations, provides a complete proof methodology for =; ∼ if two processes are
behaviourally indistinguishable there is an asynchronous bisimulation that relates
them.

2.8 Questions
1. Prove that a relation R over aPi processes is contextual, according to Definition 2.5,
if and only if P R Q implies C[P] R C[Q] for every static context C[−].
2. If the axiom (s-flip) from Figure 2.3 is dropped from the definition of structural
equivalence does Corollary 2.16 still remain true?
What about when either of the axioms in (s-stop) are dropped?
3. Prove that =
∼ is an equivalence relation.
4. Show that P ≡ Q implies P = Q.
µ µ∼
5. Prove that ≡ ◦ −→ a ⊆ − → a ◦ ≡ .
6. If n does not appear in the free names of P show that (new n) P ≡ P.
7. Prove that an asynchronous bisimulation up to ≡ for aPi is also an asynchronous
bisimulation.
8. Show that b?c!  b?c! ⊕ stop where  is defined in Definition 2.23.
 2.8 Questions 53

9. Complete Example 2.29, to show that c?c! = ∼ stop .

10. Let us say the mapping σ over Names is injective for a subset N of Names whenever
σ (n) = σ (m) implies n = m, for all n, m in N .
• Suppose σ is injective for fn(P), and P −→ Q. Prove Pσ −→ Qσ .
• Prove that if σ is injective for fn(P) ∪ fn(Q) then P = Q implies Pσ = Qσ .
∼ ∼
Here Rσ denotes the result of substituting every occurrence of n in R by σ (n),
renaming bound names as necessary in order to avoid the capture of bound names.
Give a counter-example to both statements, when σ is not injective.
11. Suppose Al and Ar are two relations over aPi processes. Then we say that R is a
bisimulation up to (Al , Ar ) if both it and its inverse satisfy the transfer property:

• Suppose R is a bisimulation up to (∼bis , ≈bis ). Show that P R Q implies P ≈bis Q.

• On the other hand show that P R Q does not necessarily imply P ≈bis Q when R is
a bisimulation up to (≈bis , ≈bis ).
12. (i) Show that P = =⇒a Q if and only if there exists some Q structurally equivalent to
c?V

Q such that P | c! V
−→∗ Q .
(ii) Use part (i) to prove that P ≈bis Q implies P ≈a Q.
13. Let Pi be the language obtained by replacing the asynchronous output c! V
in aPi with
c! V
.P. The reduction semantics for the new language is obtained by replacing the
rule (r-comm) in Figure 2.4, with

(r-syn.comm)
c! V
.P | c?(X ) R −→ P | R{|V/X |}

Give a characterisation of reduction barbed congruence, =, ∼ for Pi, in analogy with

Theorem 2.39.
14. Give a characterisation of the equivalence , defined in Definition 2.23, for the language
Pi.
15. Adapt the characterisation of  for Pi given in the previous question to the language
aPi.
16. A relation R over aPi is called an acs-bisimulation if it and its inverse satisfy the
µ
following transfer property: whenever P R Q and P −→ P  then
µ̂
• if µ is an output action, or τ , then Q =⇒ Q for some Q such that P  R Q
• otherwise if µ is an input action c?V then
54 The asynchronous PI-CALCULUS
µ̂
– either it is again matched in the standard way, by Q =⇒ Q such that P  R Q
τ ∗    
– or Q −→ Q for some Q such that P R (Q | c! V
).
It is argued in [2] that these forms of bisimulation are more convenient than the standard
bisimulations in the asynchronous lts given on page 45.
Prove that P ≈a Q if and only if there is an acs-bisimulation R such that P R Q.
17. Prove c?(x) (c! x
| c?(x) R) = ∼ c?(x) R for any term R whose free variables include at
most x.
18. Let Eab denote the process rec z. (a?(x) b! x
|z) | rec z. (b?( y) a! y
|z). Show
Eab = ∼ stop.
19. Let us say a relation R over aPi processes is pcontextual if it satisfies the first clause
of Definition 2.5: P1 R P2 implies P1 | Q R P2 | Q and Q | P1 R Q | P2 for every
process Q. Then let = ∼p be the largest relation over processes that is reduction-closed,
preserves observations, and is pcontextual.
Prove P = ∼ Q if and only P = ∼p Q.
20. Let aPil be the language obtained by omitting the construct (if then v1 = v2 then
R1 else R2 ) from aPi. Show that (full-abstraction), Theorem 2.39, no longer holds
for aPil .
 3
Types for aPi

In this chapter we look at type systems for the language aPi. The traditional view
of types is that they provide an aid to programmers to avoid runtime errors during
the execution of programs. We start with this view, explaining what runtime errors
might occur during the execution of aPi processes, and design a type system that
eliminates the possibility of such errors.
We then modify the set of types, so that they implement a more subtle notion of
resource access control. Here the resources are simply channels, and the more subtle
type system enables access to these resources to be managed; that is read and write
accesses can be controlled. The view taken is that one no longer programs directly
with resource names. Instead programming is in terms of capabilities on these
names, the ability to read to or write from a particular resource. These capabilities
are managed by the owners of resources and may be selectively distributed to be
used by other processes.

3.1 Runtime errors

The traditional use of types and type checking is to eliminate runtime errors in high-
level programs. Specifically types are annotations inserted into the program text by
the program designer, or inferred automatically by a type inference system, which
indicate the intended use of various resources. Then prior to execution the annotated
program is typechecked, that is syntactically analysed, to ensure that the behaviour
of the program will indeed respect the intended use of these resources. This static
analysis is such that when a program successfully passes it cannot produce a runtime
error. In general the analysis required will depend on the kind of runtime errors that
one wishes to avoid. To focus the discussion let us consider some simple errors that
can occur during the computation, or reduction, of an aPi process.
There are base values in aPi, such as integers and booleans, and suppose we
also had in the language some operators for manipulating base values, such as

55
56 Types for aPi

a successor function succ for integers or not on booleans. Then we may have
processes in which a value of one type finds itself in a context where a value of a
different type is expected:

c! 0
| c?(x) d ! not(x)

This obviously leads to a runtime error that we would like to avoid.

Without these operators on data the existence of base values can still lead to
problems; they may be accidentally mistaken for channels. For example in

c?(x) x! v

the channel c is obviously expecting to receive a channel. But as part of the larger
system
c! true
| c?(x) x! v
(3.1)
it will actually receive the boolean value true. This is another kind of error we
would like to eliminate.
Even ignoring base values, there are also errors that can arise because of the
shape of values being transmitted through channels, so-called arity mismatches.
For example the process
c?(x, y) x! y
(3.2)
expects a pair of values, the first of which incidentally should be a channel. But in

c! v
| c?(x, y)y! x
(3.3)

it is only sent a single entity.

In the previous chapter we have also indiscriminately used the same variables
as place-holders for values and for recursively defined processes. This imprecision
can also lead to problems. In the process

rec x. (a?(y) x! y
| x) (3.4)

there is obviously a misunderstanding with respect to the role of the variable

x; it is used both as a place-holder for channels and for processes. A similar
misunderstanding occurs in
c?(x) (x! v
| x)
Our static analysis should also preclude such misunderstandings about variables.
We formalise the notion of runtime error as a predicate on processes, that is
closed terms. One such definition is the least contextual relation satisfying the rules
given in Figure 3.1. The three axioms (err-chan), (err-comm) and (err-rec) are
defined precisely with the three different examples above, (3.1), (3.3) and (3.4), in
 3.1 Runtime errors 57

Figure 3.1 Runtime errors in aPi

mind, while the rule (err-str) and the implicit contextual rules give more contexts
in which these errors might occur.
So the object of our analysis is to ensure that if a process P passes then it will
never give rise to a term Q such that Q −→err ; that is for every Q such that P −→∗ Q
we should have Q  −→err .

Let us now investigate briefly what form this static analysis should take. If we
look at example (3.1) above it is not clear which sub-process, the sender or the
receiver, is at fault. It actually depends on the intended use of the channel c, either
to transmit boolean values, or to transmit channels. In the current description of
the process there is no indication of this intention. In fact we need to augment the
language with a facility for indicating the intended use of channels. When a new
channel is declared it must have associated with it a declaration type, indicating
the valid uses to which it may be put. Thus in
(new c : D)(c! true
| c?(x) x! v
) (3.5)
if the declaration type D indicates a boolean channel, that is a channel for carrying
boolean values, then the right-hand process is misusing c, while if it indicates a
channel that carries channels the fault lies with the left-hand one.
In general the declaration type of a channel should indicate the kind of values that
it can handle. These could be integer values, boolean values, or in turn channels.
But looking at the example (3.3) above the type should also indicate the structure
of the value. Here one process thinks it is receiving a pair of values while the other
is sending a single identifier.
We also need to differentiate between the different kinds of channels that can be
transmitted. In
c?(x) x! a

we can deduce that c carries channels but a priori there are no constraints on the
transmitted value a. However in
(c! d
| d ?(y) y! 0
) | c?(x) x! a
(3.6)
58 Types for aPi

Figure 3.2 Simple types for aPi

we see that it is further constrained to only carry channels that in turn can carry
integer channels. If the value output on y were changed to true then the declaration
type of c would have to indicate that it transmits channels that in turn transmit
boolean channels.
The precise definition of the types, called simple types, is given in Figure 3.2,
where they are classified into different kinds. The most important is that of channel
type, rw T
, where T denotes the type of values that can be transmitted. Thus,
following our discussion, in (3.6) the channel c should have the declaration type
rw rw rw int

while in (3.2) we would expect it to have a declaration type of the

form rw (rw T
, T)
for some type T.
Note that we have introduced a separate class of declaration types, D, although
the only allowed declaration types are channel types. This redundancy is convenient
for future developments, and we will tend to confine the use of declaration types
to the process language.
Notation 3.1 We use
s
 T : ty
to indicate that T is a well-formed type; again this is notation that will be more
significant in later developments. Also if C is the type rw A
then A is referred to
as the object type of C.

So the static analysis of a process will be relative to a collection of associations

from channel names to their declaration types, indicating their intended use.
This will be called a type environment. Moreover as the analysis proceeds this
environment will be augmented. For example if we are analysing the process in
(3.5) above in a given environment we will end up analysing the sub-process
c! true
| c?(x) x! v

in the environment augmented by the association of c with its declaration type D.

This in turn will lead to the analysis of
c?(x) x! v

 3.1 Runtime errors 59

Figure 3.3 Simple type environments for aPi

and hence that of the open term

x! v

where now the environment will need a type to associate with the variable x; this
will be the object type of D. But what this latter point also implies is that type
environments need to associate types not only with names but also with variables.
Essentially type environments are finite lists of type associations, pairs of the
form u : A. But in order to check the correct use of recursion variables we also
need to include type associations of the form x : proc. This will indicate that x is
only to be used for the purpose of a recursive definition; it is important to realise
that this special proc will only play a role in the construction of type environments,
and will not be used, for example, to type values. So let us introduce a further
meta-variable for the class of types that can appear in environments:
E ::= A | proc (3.7)
Then an environment will have the form
u1 : E1 , u2 : E2 , . . . , un : En , n ≥ 0
subject to some mild restrictions. Rather than impose these restrictions globally let
us give a formal definition of what it means to have a valid type environment.
In Figure 3.3 we give rules for inferring valid environments, using judgements
of the form
 s env
The first rule, an axiom, says that the empty association list is a valid type
environment while the second says that an existing environment may be augmented
by adding a new identifier, a name or a variable, and an associated channel type
C; here dom() is the set of identifiers that have an associated type in . We are
also allowed to add new variables assigned to base types, with (e-new.base) and
new recursion variables, with (e-proc); here base ranges over the collection of
60 Types for aPi

Figure 3.4 Typing values in aPi

base types, which we leave unspecified. This is perhaps being overly formalistic,
as basically a valid type environment is a finite type association list, a list of pairs
u : C, x : base or x : proc, where each identifier has a unique entry. But later we
will see that the formation of type environments will get non-trivial, and thus we
will make a distinction between an association list and a valid type environment.
We will also use the notation ,   to denote the association list obtained by adding
on the associations in   to those in ; of course there is no guarantee that the
resulting association list is a valid type environment.
The association between identifiers and types determined by an environment
can be generalised to arbitrary values V , by structural induction, and the rules for
making the judgements
 s V : T
are given in Figure 3.4. The intuition behind  s V : T is that relative to the
environment  the value V may be used anywhere a value of type T is required.
To deal with base values we assume base types are actually sets of base values; for
example int and bool are the set of integers, booleans respectively. Then the rule
(sty-base) assigns to the base values the type to which they belong.

3.2 Typechecking with simple types

Rather than giving an algorithm for analysing processes and their correct use
of channels, we will give a typechecking system, a set of inference rules for
establishing that a process term is well-typed relative to a given type environment
; that is we check it uses identifiers according to the constraints laid down by
. Type inference would then consist of an algorithm that given a process term P
constructs, if possible, a valid type environment relative to which P is well-typed.
As explained in the previous section, the process terms will come from an
embellished version of aPi, called typed aPi, in which bound names have associated
with them a declaration type. Formally the language is obtained by replacing the
 3.2 Typechecking with simple types 61

name creation construct

(new n) T (3.8)

in Figure 2.1 with

(new n : D) T (3.9)

We can still view the reduction semantics of Chapter 2 as applying to typed aPi,
simply by viewing the unannotated term (3.8) as standing for any term of the
form (3.9). Indeed it is appropriate that the reduction semantics should not refer
to the types of any of the names involved. Moreover we will continue with this
view, omitting the declaration types in terms unless they are directly relevant to the
discussion. However formally we must define structural equivalence, an important
component of the reduction semantics, as a relation over typed processes. So the
defining axioms, in Figure 2.3, must be interpreted as acting on typed processes.
For example (s-extr) now means that for every type D,

(s-extr) (new n : D)(P | Q) = P | (new n : D) Q if n ∈ fn(P)

and the second part of (s-stop) reads

(s-extr) (new n : D) stop = stop

There is a more significant change to (s-flip), which now must read

(s-flip) (new n : Dn ) (new m : Dm ) P = (new m : Dm )

(new n : Dn ) P if n  = m

Declarations can only be flipped if the names involved are different.

The inference rules for typechecking are given in Figure 3.5 where the
judgements are of the form
 s
 R : proc

where R is an arbitrary, possibly open, process term. There is one rule for each
construct in the language. Most of the rules are straightforward. (sty-stop) says that
term stop represents a well-typed process relative to any valid type environment. To
typecheck R1 |R2 it is sufficient to typecheck the components R1 and R2 individually,
(sty-par), while to typecheck (new n : D) R relative to the environment  we need
to check the term R relative to the augmented environment , n : D. The treatment
of if v1 = v2 then R1 else R2 also uses induction.  must know the values v1 , v2
and in turn the terms R1 and R2 must be typechecked.
62 Types for aPi

Figure 3.5 Inference of simple types in aPi

The only non-trivial rules are for input and output, which in turn refer to the
judgements in Figure 3.4 for assigning types to values. The term u! V
is well-typed
relative to  if
•  can assign to u a channel type
•  can assign to the value being sent, V , the object type of that assigned to u.

The input rule (sty-in) says that for u?(X ) R to be well-typed relative to 
• u must have a channel type of the form rw T
in 
• the residual R must be well-typed in an augmented type environment.

This new environment is formed by adding appropriate associations between

the variables in the pattern X and the components of the type T. Formally the
extension , X :T
should be viewed as the result of appending to the environment
 a list obtained by structural induction from the pattern X and the type T. It
will be convenient, for later use, to have a more general construction for these
association lists.

Definition 3.2 (constructing environments) The association list V :T

is defined
by induction on the structure of the value V . Note this is a partial operation; for
example it will not give a result if the structure of V does not match that of T.
• If V is a base value bv then T must be the base type of bv and in this case the result is
the empty list.
• If V is a variable x and T is a base type base then the result, x:base
, is the singleton
list x : base.
• If V is an identifier u and T is a channel type C the result, u:C
, is the singleton
list u : C.
 3.2 Typechecking with simple types 63

• If V is (v1 , . . . , . . . , vn ), for some n ≥ 0, the new list is only defined if T has a

corresponding structure (A1 , . . . , An ). The new list is then constructed by induction:

v1 :A1
, . . . , vn :An

Because variables have unique occurrences in patterns we are assured that X :T

is
a valid environment, whenever it is defined. But this is not always true of the more
general construction V :T
. 

Referring once more to the rule (sty-in), one consequence of this definition is that
there is no possibility of typechecking a term of the form u?(X ) R relative to an
environment unless the object type of u in that environment matches the pattern X .
Before looking at some examples it is worth emphasising the way in which we
treat bound variables in typing judgements. Throughout we make the restriction
that typing rules can only be applied to judgements
 
s
R : proc
when the domain of  does not contain any bound name in R; indeed this is another
application of the Barendregt convention, Convention 2.4. So for example in the
rule (sty-new) we know that n is new to  and therefore the extended environment
, n : D is well-formed, assuming  is. Similarly in (sty-in) we know that all the
variables in the pattern X are new to  and therefore , X :T
will be a valid
environment, assuming X matches T . But there may be times, for example when
generating the proof of a typing judgement, when we are required to form a sub-
judgement of the form
 s (new n : D) R : proc (3.10)
where n already appears in . In such cases we recall the fact that terms actually
denote equivalence classes under α-conversion, and we interpret rules involving
bound variables, such as (sty-new), as saying that to infer (3.10) above it is
sufficient to infer
 s (new m : D) R : proc
for some m not in the domain of , such that
(new m : D) R ≡α (new n : D) R
In the sequel we will say a term R is well-typed if it can be typechecked, that is
if there is some environment  such that  s R : proc can be inferred from the rules
in Figure 3.10. It will also often be convenient to drop these occurrences of proc,
rendering typing judgements simply as  s R.
Example 3.3 Consider the typechecking of the process
(new d : D)(c! d
| d ?(y) y! 0
) | c?(x) x! b

64 Types for aPi

a slight modification of that in (3.6) above. Let d be the type environment

d : rw rw int

Then an application of (sty-out) followed by (sty-in) gives

d s
 d ?(y) y! 0

Let c,d denote the environment

c : rw rw rw int

, d : rw rw int

Since this is an extension of d we also have

c,d 
s
d ?(y) y! 0

and using (sty-out) again, followed by (sty-par), we obtain

c,d s
 c! d
| d ?(y) y! 0

Now provided D is exactly the type rw rw int

an application of (sty-new) gives

c s
 (new d : D)(c! d
| d ?(y) y! 0
)
where c is the list c : rw rw rw int

. Finally let c,b denote

c , b : rw int

Then another application of (sty-out), (sty-in) and (sty-par) gives

c,b s
 (new d : D)(c! d
| d ?(y) y! 0
) | c?(x) x! b

It is easy to see that for the process to be well-typed the form of the type D is
determined by that of c. Also all the entries in c,b are necessary to type this
process in the sense that if  is any other environment for which
 s
 (new d : D)(c! d
| d ?(y) y! 0
) | c?(x) x! b

can be derived, then dom() must include at least b, c and  must coincide with
c,b on these names.

Example 3.4 [Typing the Compute Server ] Recall from Example 2.10 that this is
defined by
primeS ⇐ rec z. (z | in?(x, y) y! isprime(x)
)
where isprime represents some test for primality. The only free name occurring in
primeS is in and therefore we should be able to type it relative to some environment
s that simply maps in to some type S. This channel expects two pieces of data, an
integer and a channel; moreover the channel will be used to return a boolean value.
So S has to be
rw (int, rw bool
)

 3.3 Properties of typechecking 65

However to formally derive the judgement

s s
 primeS (3.11)
we need to add a rule for handling the operation isprime:
(sty-op)
 s u : int
(3.12)
 s isprime(u) : bool
With this new rule the derivation of (3.11) is straightforward. It relies on establishing
two judgements:
, z : proc s z : proc
, z : proc s in?(x, y) y! isprime(x)

The second uses an application of (sty-in), followed by (sty-out), and the above
(sty-op). The former requires an instance of a value judgement, (sty-id).
Now consider the typed version of the clients:
Clienti (v) ⇐ (new r : Dr ) in! v, r
| r?(x) printi ! x

The declaration type of the reply channel Dr is determined by that of in; it has to
be rw bool
. Assuming that v is an integer one can infer
s , printi : rw bool
s Clienti (v)
Summing up, we can type the overall system
Sys ⇐ Client1 (27) | Client2 (29) | primeS
relative to any type environment s such that
s s
 in : S, printi : rw bool

3.3 Properties of typechecking

The object of this section is to prove that typechecking provides a successful static
analysis for the avoidance of runtime errors. Specifically, we prove that if there
exists a type environment  such that  s P then whenever P −→∗ Q we are
assured that Q −→err . The proof strategy is divided into two steps:
(i) Show that well-typed processes do not contain runtime errors. That is  s Q implies
Q  −→err . This is referred to as type safety; see Theorem 3.13.
(ii) Show that being well-typed with respect to a type environment is an invariant under
reduction. That is  s P and P −→ Q implies  s Q. This is often referred to as
subject reduction; see Theorem 3.12.
66 Types for aPi

Type safety is usually a straightforward inductive proof, but subject reduction

depends on a substitution result, which roughly says that variables in typing
judgements can be substituted by appropriately typed values. To prove this result
we need, in turn, to develop a series of properties of the formal systems for making
typing judgements. Although we are only interested in the typing of processes,
this depends on the type system for values, and even the system for constructing
valid environments; see the rule (sty-stop) in Figure 3.5. So properties of all
three formal systems have to be considered. The vast majority of these properties
have straightforward proofs, usually by rule induction on typing judgements. But
these proofs are usually long, being tedious case analyses on the derivation of
judgements. Consequently we concentrate on elaborating the precise properties
required, leaving many of the details in the proofs to the reader.
First let us look at some of the many natural properties one would expect of the
formal system defined in Figure 3.5. Perhaps the simplest is:

Lemma 3.5 (sanity checks)

(i) ,   s env implies  s env
(ii) If  s u : E then  s env
(iii) If  s R : proc then  s env.

Proof: The first statement is proved by induction on the size of   . The base case
is when this is empty, which is trivial. Otherwise it has the form   , u : E and the
judgement

,   , u : E s env

must have been inferred from one of the three rules (e-new.id), (e-new.base) or
(e-proc). But the premise in each rule allows us to conclude that ,   s env. We
can now apply induction to this statement to obtain the required  s env.
The proofs of the second and third statements are by induction on the derivation
of the judgement in question; it is sufficient to carry out a case analysis on the last
rule used. Thus the proof of the second statement has four cases, since the proof of
the judgement could end in any of the four rules in Figure 3.4, while the proof of
the third has eight cases, arising from the seven rules in Figure 3.5, and the trivial
possibility of an application of (sty-id), when R is a variable. Note that some of
these cases, for example the rule (sty-new), rely on part (i), while others, such as
(sty-in), rely on part (ii).

One minor, but crucial, property of the typing system in Figure 3.4 is that, relative
to a given environment, it assigns unique types to values; however the reader should
be warned that this will not be true of later typing systems.
 3.3 Properties of typechecking 67

Proposition 3.6  s V : T1 and  s V : T2 implies that T1 and T2 are identical.

Proof: An easy proof by induction on the structure of V ; for each possible case
there is only one applicable typechecking rule, depending on the type T.

This result means that we can view a type environment  as a function that maps
identifiers in its domain dom() to types. We use (u) to denote the type associated
with the identifier u.
Although we have been careful in the construction of environments, it turns out
that the order in which type associations are added does not really matter:
Proposition 3.7 (interchange) Let  and   denote the lists 1 , u : E, u : E , 2
and 1 , u : E , u : E, 2 respectively. Then
•  s env implies   s env
•  s V : T implies   s V : T
•  s R implies   s R.

Proof: The first statement is proved by induction on the size of   , with the only
non-trivial case being when it is empty where a case analysis is required on the
forms of u, u ; the inductive case is taken care of by Lemma 3.5(i).
The other two statements are proved by rule induction, and an analysis of the
last rule used. The essential fact underlying these results is that any derivation of
a judgement using  can be replaced by one using   ; environments have unique
entries for identifiers and in typechecking they are essentially only used as look-up
tables.

The following are more substantial, but the structure of the proofs are similar; they
also require the property (interchange).
Proposition 3.8
• (Weakening) Suppose ,   s env. Then
–  s V : T implies ,   s V : T
–  s R implies ,   s R.

• (Strengthening)
– If , u : E s V : T where u does not occur in V , then  s V : T.
– If , u : E s R where u does not occur in R, then  s R.

Proof: The proof details, which are considerable but mundane, are left to the reader;
here we only give their structure, and some typical example cases.
• (Weakening): Both cases are proved by rule induction, and an analysis of the last rule
used in the derivation. For example if  s V : T is proved by an instance of (sty-id),
then exactly the same rule can be applied to the extended environment ,   , to conclude
,   s V : T.
68 Types for aPi

Similarly suppose  s R because of an application of (sty-new). Then R must be of the

form (new n : D) R1 , where by Barendregt’s convention we can assume that n is new to
both  and   . Moreover because of the application of (sty-new) we know , n : D s R1 .
But the type formation rules, specifically (e-new.id), ensure that ,   , n : D s env,
and a sequence of applications of (interchange) therefore gives , n : D,   s env. So
induction can be applied, to give , n : D,   s R1 . Another sequence of applications of
(interchange) leads to ,   , n : D s R1 . Now (sty-new) gives the required ,   s R.
• (Strengthening): Here the structure of the proof is identical, using rule induction and an
analysis of the last rule used. Because of the side conditions, each application of a rule
using the environment , u : E can be replaced by an application of the same rule using
. But once more the case (sty-new) requires the property (interchange).

The most important technical property of the type inference system is that in some
sense typing is preserved by the substitution of values into variables, provided the
types assigned to these values and variables coincide.

Proposition 3.9 (substitution)

(i) (values) Suppose  s v : A and , x : A s V : T. Then  s V {|v/x|} : T.
(ii) (processes) Suppose  s v : A and , x : A s R. Then R{|v/x|} is well-defined and
 s R{|v/x|}.
(iii) (recursion) Suppose  s R1 and , x : proc s R2 . Then R2 {|R1/x|} is well-defined and
 s R2 {|R1/x|}.

Proof: The first result is a straightforward induction on the derivation of , x : A s

V : T from the rules in Figure 3.4. The only delicate case is the use of the axiom
(sty-id), where a case analysis is required on whether or not v is the variable x.
Let us consider the second result, for processes. Under the assumption that  s
v : A, suppose , x : A s R. We show, by rule induction, that this can be transformed
into a derivation of  s R{|v/x|}. We examine the last rule used in the derivation of
, x : A s R, which is either from Figure 3.5, or an application of (sty-id) from
Figure 3.4 to infer a variable. For simplicity we use J  to denote J {|v/x|} for any
syntactic object J . Using this notation we have to show  s R . There are eight
possibilities.

• (sty-out): Here the term R has the form u! V

and we must have

, x : A s u : rw T

, x : A s V : T

for some transmission type T. We can apply part (i) of the proposition to both judgements
to obtain  s u : rw T
and  s V  : T. An application of (sty-out) now gives the
required  s u ! V 
.
 3.3 Properties of typechecking 69

• (sty-in): Here the term R is u?(Y ) S and we know

, x : A s u : rw T

, x : A, Y :T
s S

for some transmission type T. Note that the ability to apply (sty-in) means that x cannot
be in the pattern Y . This time we apply part (i) of the proposition to the first judgement
to obtain

 s
 u : rw T

To the second we need to apply (interchange), Proposition 3.7, possibly a number of

times, to obtain

, Y :T
, x : A s S

Also (weakening), from Proposition 3.8, applied to the hypothesis  s v : A, gives

, Y :T
s v : A. So induction may be applied, to obtain

, Y :T
s S 

Now (sty-in) gives the required

 s
 u ?(Y ) S  that is  s
 R

All other cases are similar, using the part (i) of the proposition or induction. But note
that the cases (sty-rec) and (sty-new) also require an application of (interchange),
while that of (sty-zero) needs (weakening).
The final result, for recursion, is proved in a similar manner, by rule induction
on the inference , x : proc s R2 . Let us examine two cases.

• (sty-proc): Here R2 is some variable y, and , x : proc s R2 is true because somewhere

in , x : proc there is the entry y : proc. There are two cases. In the first x and y coincide,
and the required result is immediate, since R2 {|R1/x|} unravels to R1 . In the second x  = y,
and so the entry must appear somewhere in ; in other words  s y. So the result is again
immediate, since R2 {|R1/x|} is y.
• (sty-new): Here R2 has the form (new n : D) R and , x : proc s R2 because , x :
proc, n : D s R. Using (interchange), Proposition 3.7, this can be rewritten as , n : D, x :
proc s R. Also (weakening), from Proposition 3.8, applied to the hypothesis  s R1 gives
, n : D s R1 .
Now we can apply induction, to obtain , n : D s R{|R1/x|}. Then an application of
(sty-new) gives  s (new n : D)((R){|R1/x|}). However using α-conversion if necessary,
or invoking Barendregt’s convention, we can ensure that the bound variable n does
not appear in R1 , and therefore the term we have just typed with respect to  is
((new n : D) R){|R1/x|}, that is the required R2 {|R1/x|}.

70 Types for aPi

There is a simple generalisation of the substitution result for processes to patterns:

Corollary 3.10 Suppose  s V : T. Then , X :T
s R implies R{|V/X |} is well-
defined and  s R{|V/X |}.
Proof: By induction on the structure of the pattern X .

We are now nearly ready to prove subject reduction. Recall that the structural
equivalence plays a large role in the reduction semantics. So let us first factor
this out.
Proposition 3.11 Suppose P ≡ Q. Then  s P implies  s Q.
Proof: This is proved by induction on the proof of P ≡ Q. The contextual rules
in the definition of ≡ pose no problem. For example suppose P, Q have the
form (new n : D) P  , (new n : D) Q and they are structurally equivalent because
P  ≡ Q . Because  s P we know , n : D s P  and therefore by induction we have
that , n : D s Q . An application of (sty-new) then gives the required  s Q.
So we need only consider the axioms in the definition of structural equivalence,
the typed versions of those in Figure 2.3. Most are straightforward, but note that
one part of (s-stop) requires (strengthening).
The only non-trivial axiom is (s-extr), which might be expected. So suppose
P s (new n : D)(P | Q), where n does not occur free in P. This could only have
been derived by an application of (sty-new) preceded by one of (sty-par) and
therefore we must have

, n : D s P
, n : D s Q

We can apply (strengthening) to the former to obtain  s P. Now an application of

(sty-new) followed by (sty-par) gives the required

 s
 P | (new n : D) Q

The converse is similar but requires an application of (weakening).

Theorem 3.12 (subject reduction for simple types) Suppose  s P. Then P −→ Q

implies  s Q.
Proof: The proof is by induction on the derivation of the judgement P −→ Q, from
the rules in Figure 2.4 and those obtained from the contextuality of reduction. The
latter are handled routinely by induction and the troublesome rule (r-str) follows
from the previous lemma. So we need only consider the axioms. Both (r-eq) and
(r-neq) are trivial. So let us consider the first two axioms.
 3.3 Properties of typechecking 71

• Suppose  s c! V
| c?(X ) R. We have to show  s R{|V/X |}, which will follow from
Corollary 3.10 if we can show that for some type T

, X :T
s R and  
s
V :T (3.13)

But we know  s c! V
from which we can obtain  s V : T1 for some type T1 . In fact
this is a type for which we also know  s c : rw T1
. In addition from  s c?(X ) R we
obtain , X :T2
s R for some type T2 , a type for which we can deduce  s c : rw T2
.
But inferred channel types are unique – see Proposition 3.6, and therefore T1 = T2 . The
result therefore follows from (3.13).
• Suppose  s rec x. B. This could only have been derived using (sty-rec) and therefore
we know , x : proc s B. We can now immediately apply Proposition 3.9 (processes) to
obtain the required  s B{|rec x. B/x|}.

Theorem 3.13 (type safety) For any process P,  s P implies P  −→err .

Proof: The proof is straightforward, which is not surprising since the typechecking
system was designed with the particular definition of −→err in mind.
We prove, by rule induction, that if P −→err then there is no  for which  s P
can be derived. Looking at the definition in Figure 3.1 we see that seven possibilities
have to be considered.

• (err-chan): Obvious. For example if v is not a name then there is no way to infer a type
for v! V
using (sty-out).
• (err-comm): This is the only case that is not completely trivial. Here P has the form
a?(X ) R | a! V
and the pattern X and value V do not match. Suppose that for some
environment  we were able to type at least a! V
. This would mean that there is a type
T, the object type of a in , such that  s V : T. But such an inference is only possible
if V matches the type T, which means that T does not match the pattern X . So the list
extension , X :T
is not defined and therefore (sty-in) cannot be used to complete the
typing of R.
• (err-rec): Here P has the form rec x. B and the substitution B{|rec x. B/x|} is not defined.
For any  we can apply Proposition 3.9 (recursion), with R1 and R2 instantiated to
rec x. B, B respectively. This implies that either   s rec x. B or , x : proc  s B. But the
latter possibility also means that  s rec x. B as the only way to infer the well-typing of
a recursive definition is with (sty-rec).

All the other possibilities follow by induction. Suppose, for example, that
(new n : D) P −→err because P −→err . By induction P is not typeable and therefore
we cannot use (sty-new), the only possible rule, to infer that (new n : D) P is
well-typed.

Combining these two results we can now conclude that being well-typed
precludes the possibility of runtime errors.
72 Types for aPi

Corollary 3.14 Suppose  s P. Then Q  −→err for every process Q such that
P −→∗ Q.
Proof: Subject reduction implies that  s Q and therefore we can apply type safety
to obtain Q −→err .

3.4 Types as capabilities

Channels are resources that are shared among processes for communication
purposes. But so far when a process gains knowledge of a channel it may make
use of it in any manner it wishes. The language aPi allows three valid uses of a
channel c:
• values, of the appropriate type, may be read from c
• values, again of the appropriate type, may be written to c
• c may be compared with other identifiers for identity.

Each of these may be viewed as capabilities on the channel c and currently

knowledge of c provides all three capabilities. But in many situations it may be
advantageous to be more discriminating in their distribution. A simple example is
provided by the memory cell Mem in Example 2.11. For the integrity of the memory
to be maintained it is important that Mem is the only process in its environment
that has read permission on the two access methods get and put. Otherwise a rogue
process could set up a rival memory cell with the same access methods but giving
spurious results; this is discussed in more depth in Example 3.15 below. In this
section we show how the typing rules in Figure 3.5 can be modified in a simple
manner so as to implement this more refined view of types. Moreover we show that
all the properties of typechecking derived in the previous section remain valid.
The previous monolithic view of channel types, in Figure 3.2 is broken down
into three separate capability types:
read: A channel name at the type r T
can only be used to read values, and use
them with at most the capabilities given by T.
write: Similarly at the type w T
it can only be used to write values, and use them
with at least the capabilities in T.
read and write: The more general type rw Tr , Tw
allows the reading of values
with at most the capabilities of Tr and at least those of Tw .
This last type is often abbreviated to rw T
when both the read and write capabilities
are the same, namely T = Tr = Tw ; however we shall see that the more general
form will be technically convenient.
The idea now is that processes no longer transmit values among themselves,
but rather transmit certain capabilities on those values. The precise capabilities
 3.4 Types as capabilities 73

transferred in a given communication are determined by the type of the channel

responsible for that communication. Referring back to Example 2.11, at some point
in its history the client obtains the names of the channels put, get, and it is the
type at which they are obtained that determines how they can be used. To discuss
this further consider an extension of that example.
Example 3.15 [A Memory Server ] Consider the following definition of a memory
service memSERV, which receives a request for a memory on the channel s,
generates a new memory, with the associated access methods put and get, and
sends them back on the reply channel, bound to x:
memSERV ⇐ rec w. s?(x) (w | (new put : Dp , get : Dg )(x! put, get
| Mem))
Here Mem is the code for a memory, given in Example 2.11. However there the
methods put and get were free; here they are bound, and in effect each time the
service is called on s a new memory, with new put and get methods, is generated;
a priori a client can have no knowledge of these yet to be created access methods.
But the client mClient, defined below, sends a request to the server, obtains the
newly created access methods and uses them as in Example 2.11:
mClient ⇐ (new r : Dr )(s! r
| r?(x, y) Clientx,y )
Clientx,y ⇐ (new a : Da )(x! 4, a
| a? (new b : Db )(y! b
| b?(z) print! z
))
The various declaration types can easily be instantiated so that the combined system
memSERV | mClient
can be typed using the type inference of the previous section. But so can the system
memSERV | badClient
that contains a rogue client badClient:
badClient ⇐ (new r : Dr )(s! r
| r?(z, w) badMem)
badMem ⇐ rec p. z?(x, y) (y! | p) |
rec g. w?(y) (y! 27
| g)
This client also obtains the two new access methods but sets up a rival service on
both, effectively pretending to be a memory cell that always contains the arbitrary
number 27; updates to this rogue memory cell leave the contents unchanged.

With capability types we can guard against such rogue clients by ensuring that
when memSERV exports the names of the new access methods the client only
obtains write permission on them. The export type of these names is determined
by the write capability on the variable x in the definition of memSERV
. . . (x! put, get
| . . .
74 Types for aPi

that, as we shall see, is determined in turn by that of the access point to the
service s.

3.4.1 Capability types and environments

Intuitively a channel at the type rw T
can be used both for reading and for writing,
that is, in the same manner as a channel at the type r T
or at the type w T
. For this
reason it is convenient to introduce a subtyping relation between these capability
types. The judgement
T1 <: T2 (3.14)
means that any value that a process has at type T1 may be used in an occurrence
where the type T2 is required. For example we will have
rw T
<: w T

because if a process has a value, say c, at the type rw int

then that process may
use the code
. . . c! 1
. . .
because this is a use of c at the supertype w int
. In (3.14) above we say T1 is
a subtype of T2 , or T2 is a supertype of T1 . This ordering <: is reasonable if we
interpret a type (informally) as the set of identifiers that can be assigned that type.
There is another informal view of a type as a set of capabilities. For example
the type rw int
represents the set of capabilities {r int
, w int
} while w int
is
the singleton set {w int
}. Under this view, to which we will often refer, (3.14)
above means that the set of capabilities T2 is a subset of T1 ; that is T1 has at least
the capabilities of T2 , and possibly more.
The informal description of capability types in Figure 3.6 has a side condition
that uses the subtyping relation on types of the form rw Tr , Tw
; here the subscripts
r , w are simply an informal indication of the role of the types concerned. Intuitively
if a channel c is known at this type one would expect that values read from c would
have at most the capabilities of values written to c; otherwise capabilities could
be manufactured spontaneously. This requirement is enforced by demanding that
Tw <: Tr . See Example 3.33 for more discussion on this point.
However formally we make no use of Figure 3.6; instead we concentrate on the
formal system determined by the rules in Figure 3.7. In this system the judgements
take the form
T1 <: T2
where of course the entities T1 and T2 are similar in structure to those described
informally in Figure 3.6. The main rule is (sub-chan.a), which is in effect
 3.4 Types as capabilities 75

Figure 3.6 Capability types for aPi – informal

Figure 3.7 Subtyping for aPi

three different homomorphic rules, for types of the form r −

, w −
and rw −

respectively. Note that <: is co-variant in r −

, as might be expected, but
contra-variant in w −
. To see why the latter is necessary suppose we allowed
w T1
<: w T2
, where T1 <: T2 , that is where a value at type T2 may have fewer
capabilities than required by T1 . This would allow the typing of

. . . a! v
. . .

for such a value v, where a reader on a may be expecting values with all the
capabilities of the type T1 . Again this is discussed further in Example 3.32.
We now use the rules of Figure 3.7 to give a formal definition of the set of
capability types, and the subtyping relation between them.

Definition 3.16 (capability types) Let us write  T : ty to mean that the judgement
T <: T can be derived using the rules in Figure 3.7. We use Types to denote the
set of all such T. Note that we have now dropped the superscript s , indicating that
we are no longer dealing with simple types.
We also have a subtyping relation between members of Types; for T1 , T2 ∈
Types let T1 <: T2 whenever the judgement T1 <: T2 can be derived from the
rules. 
76 Types for aPi

It is worthwhile noting that this formal definition implements the informal constraint
on the construction on channel types given in Figure 3.6:
Lemma 3.17
(i) If  rw Tr , Tw
: ty then Tw <: Tr .
(ii) If the judgement T1 <: T2 can be derived then  T1 : ty and  T2 : ty.

Proof:
(i)  rw Tr , Tw
: ty means that we can derive  rw Tr , Tw
<: rw Tr , Tw
. The only rule
for doing so is (sub-chan.a), the premise of which ensures the required result.
(ii) A simple proof by induction on the derivation of the judgement T1 <: T2 . For example
suppose these are rw Tr1 , Tw1
, rw Tr2 , Tw2
respectively, and the judgement was inferred
via an application of (sub-chan.a). This means we already have the judgements Tr1 <:
Tr2 , Tw2 <: Tw1 and Tw1 <: Tr1 , to all of which we can apply induction. So for example
this gives Tr1 <: Tr1 , Tw1 <: Tw1 , and therefore, because we already know that Tw1 <: Tr1 ,
we can apply the same rule to establish  rw Tr1 , Tw1
: ty. Establishing  rw Tr2 , Tw2
: ty
is equally straightforward, since Tw2 <: Tw1 <: Tr1 <: Tr2 .

Lemma 3.18 Types ordered by <: is a pre-order.

Proof: Reflexivity is trivial since T is in Types only if we can derive T <: T.
Suppose T1 <: T2 and T2 <: T3 . One can prove by induction on the derivation
of the latter that T1 <: T3 . The proof proceeds by a case analysis on the last rule
applied. As an example suppose this rule is (sub-chan.a) with the conclusion
rw Tr2 , Tw2
<: rw Tr3 , Tw3
(3.15)
So T2 , T3 are of the form rw Tr2 , Tw2
, rw Tr3 , Tw3
respectively. We know, because
(sub-chan.a) was applied, that Tr2 <: Tr3 and Tw3 <: Tw2 .
Because T1 <: rw Tr2 , Tw2
, one can show that T1 must also be of the form
rw Tr1 , Tw1
, and, because (sub-chan.a) is the only rule that could be used to make
this inference, we must also have Tr1 <: Tr2 and Tw2 <: Tw1 .
Induction now gives Tr1 <: Tr3 and Tw3 <: Tw1 . Also by Lemma 3.17(ii) we know
rw Tr1 , Tw1
is a valid type, and therefore by part (i) that Tw1 <: Tr1 . So we have all
the information required to use (sub-chan.a) to deduce T1 <: T3 .
There are many other possibilities for the conclusion (3.15) to the application of
(sub-chan.a), and there are the three other rules in Figure 3.7 to consider. But in
each case similar inductive reasoning can be used to conclude T1 <: T3 . The case
analysis can be helped by a so-called inversion of subtyping result, which, given
T2 <: T3 and the structure of T3 , determines the structure of T2 ; see Question 6 at
the end of the chapter.

In fact we can easily show that this pre-order is actually a partial order, that is <:
is anti-symmetric over capability types. However we will not use this property.
 3.4 Types as capabilities 77

Intuitively a type represents a set of capabilities, and the combining of capabilities

has the informal counterpart at the level of types as a greatest lower bound operation.
However only certain forms of capabilities, those that are in some sense consistent,
may be combined together. For example the types r int
and w bool
cannot be
combined as in a well-typed process one cannot have an identifier with both these
types. But r int
and w int
can be combined to obtain rw int
; this is the greatest
lower bound of r int
and w int
with respect to <:.
Definition 3.19 (partially complete pre-orders) In a pre-order A, <
let us write
a ↓ b to mean that there is some element c such that c < a and c < b; in other
words a and b have a lower bound. Similarly we write a ↑ b to mean they have an
upper bound.
Then A, <
is said to be partially complete or pc if for every pair of elements
a, b in A
• a ↓ b implies a and b have a greatest lower bound (glb), denoted a  b; this element is
also a lower bound and it dominates all other lower bounds. Thus a  b < a, a  b < b,
and c < a  b whenever c < a and c < b
• if they have an upper bound, a ↑ b, then they have a least upper bound (lub), denoted
a b.

Note that lubs and glbs need not be unique, although they will be whenever A, <

is a partial order. Nevertheless we still use the standard notation a b and a  b for
arbitrarily chosen instances. 
This definition of upper and lower bounds can be generalised from pairs of elements
to subsets of a pre-order A. For example if S ⊆ A we will write S ↓ to mean that
there is some element c in A with the property that c < a for every a in S. One can
show that if A is partially complete then for every non-empty finite subset S, S ↓
implies S has a greatest lower bound, which we will denote as S; see Question 5
at the end of the chapter.
Proposition 3.20 The pre-order Types, <:
is partially complete.
Proof: The proof proceeds in three steps. First we define two symmetric partial
operations on types, T1  T2 and T1 T2 , by simultaneous structural induction.
The base case is when both T1 and T2 are base types, where we have the obvious
clauses:
int  int = int int int =
bool  bool = bool bool bool = bool
Other base types would have similar clauses.
For channel types T1  T2 may be read off from the following schema, where
now superscripts r,w are used to indicate the role of the type expressions to which
78 Types for aPi

they are applied:

w T1w
 w T2w
= w T1w T2w

r T1r
 r T2r
= r T1r  T2r

r T1r
 w T2w
= rw T1r , T2w
provided T2w <: T1r
r T1
 rw T2r , T2w
= rw T1r  T2r , T2w

r provided T2w <: T1r

w T1w
 rw T2r , T2w
= rw T2r , T1w T2w
provided T1w <: T2r
rw T1r , T1w
 rw T2r , T2w
= rw T1r  T2r , T1w T2w
provided T1w <: T2r , T2w <: T1r
This is interpreted as saying that if the right-hand side is defined then so is the
left-hand side; moreover symmetric instances, such as w T1w
 r T2r
, have been
omitted.
There is a similar, but more restricted, schema for calculating T1 T2 :
w T1w
w T2w
= w T1w  T2w

r T1r
r T2r
= r T1r T2r

r T1r
rw T2r , T2w
= rw T1r T2r , T2w

w T1w
rw T2r , T2w
= rw T2r , T1w  T2w

rw T1r , T1w
rw T2r , T2w
= rw T1r T2r , T1w  T2w

Finally the definitions are extended to tuple types in the obvious manner:
(T1 , . . . , Tn )  (T1 , . . . , Tn ) = (T1  T1 , . . . , Tn  Tn )
(T1 , . . . , Tn ) (T1 , . . . , Tn ) = (T1 T1 , . . . , Tn Tn )
The second step is to establish:
• if there is a Tl such that Tl <: T1 and Tl <: T2 then T1  T2 exists
• if there is a Th such that T1 <: Th and T2 <: Th then T1 T2 exists.

The proof is by simultaneous induction on the structure of Tl and Th , and essentially

proceeds by case analysis. For example if Tl has the form rw Tlr , Tlw
then T1 and
T2 can take many forms. Let us look at one possibility, when T1 is rw T1r , T1w
and
T2 is w T2w
. According to the above schema, to show T1  T2 exists we need to
establish
(1) T1w T2w exists
(2) T2w <: T1r .

However because of the rules of subtyping, in Figure 3.7, we know that T1w <: Tlw
and T2w <: Tlw , and so by induction we have (1). The subtyping rules also give
Tlr <: T1r . Moreover they enforce the invariant Tlw <: Tlr , from which (2) follows.
Note incidentally that these two conditions ensure that T1  T2 , that is
rw T1r , T1w T2w
, is a valid type; since T1 is a valid type we know T1w <: T1r ,
and so using (2) we obtain the consistency requirement T1w T2w <: T1r .
 3.4 Types as capabilities 79

Figure 3.8 Capability type environment for aPi

The final step is to show that whenever these operations are defined the resulting
types have the required properties:
• Tl <: T1  T2 for every Tl such that Tl <: T1 and Tl <: T2
• T1 T2 <: Th for every Th such that T1 <: Th and T2 <: Th .

Again the proof is by simultaneous induction on Tl and Th and proceeds by case

analysis.

The partial meet operation on types enables us to combine capabilities that

a process may gradually accumulate on a given resource. In fact it will be
technically convenient to generalise the notion of type environments to take this
gradual accumulation of capabilities into account. The revised definition is given
in Figure 3.8, where now an environment  may be extended by an entry u : A,
provided this information is consistent with ; this is written  ↓ u : E and means
that E has a lower bound with any E such that   u : E . That is, to extend  with
u : E the identifier u no longer needs to be new to ; but the capability E cannot
contradict any knowledge  already has of u. Note that the new rule, (e-ext),
subsumes the original rule (e-new.id) in Figure 3.3, as  ↓ u : E is vacuously true
whenever u is new to ; similarly with (e-base).
So for example
. . . c : r int
, . . . , c : w int
(3.16)
is now a valid environment, as the final entry c : w int
is consistent with the
environment . . . , c : r int
, . . ., assuming these are the only entries for c, whereas
. . . c : r int
, . . . , c : w bool
 env

cannot be derived because c : w bool

is not consistent with it. The environment
(3.16) above will occur when typechecking a process that first receives the resource
c with the capability r int
and subsequently receives the extra capability w int
on
it. It is also worth pointing out that the addition of this side-condition means that
80 Types for aPi

Figure 3.9 Typing values with capability types aPi

formally the judgements for valid type environment formation and for assigning
types to values need to be defined by simultaneous induction.
This assignment of types to values also needs to be adjusted; the new rules are
given in Figure 3.9. The first (new) one, (ty-sub), merely says that any name known
at a type A, may be used at any supertype A of it; this is perfectly understandable
via the (informal) intuition of a type being a set of capabilities and A <: A meaning
A is a subset of A. The second (new) rule (ty-meet) allows us to combine known
capabilities of a given name. Thus if  denotes the environment (3.16) above,
(ty-meet) enables us to deduce   c : rw int
. As stated, this rule has a slight
lacuna as a priori we do not necessarily know if the meet A  A exists. So for the
moment let us say that this rule can only be applied whenever we know it exists. But
as we shall see, in Proposition 3.26 below, the premises actually always guarantee
its existence.

3.4.2 Type checking

Having discussed the subtyping structure on the capability types we now describe
the rules governing typechecking for processes. There are three modifications, given
in Figure 3.10, two of which are very natural. The new rule (ty-in) is a minor
variation of (sty-in). To infer   u?(X ) R it is now sufficient to have only the
read capability on u; that is   u : r T
for an appropriate type T, rather than as
in Figure 3.5   u : rw T
. Similarly in the new rule (ty-out) it is sufficient to
have the output capability on the channel concerned.
It is worthwhile examining the effect of subtyping on these two rules. As an
example suppose rw Tr , Tw
is the only entry for c in . At what type is it necessary
to have a value v in order for the output

c! v

to be well-typed? Suppose Tv is the only entry for v in . Then (ty-out) and

(ty-sub) demand the existence of a type T such that

Tv <: T and rw Tr , Tw
<: w T

 3.4 Types as capabilities 81

Figure 3.10 Inference of capability types in aPi

Because of the contra-variance of w −

this amounts to the constraint that

Tv <: Tw

In other words to send a value on the channel c the value must have at least all the
capabilities required by the output type Tw .
A similar analysis will show that c?(x) R(x) is well-typed if the residual R(x)
uses x with at most the capabilities required by the input type Tr . That is we must
be able to infer
, x : Tx  R(x)

for some type Tx such that Tr <: Tx . However there is a further implicit constraint.
In the type entry for c, rw Tr , Tw
, there is the constraint Tw <: Tr ; Tr can have
at most the capabilities of Tw . Effectively the constraint on Tx is Tw <: Tr <: Tx .
So in the best possible world the receiving code R(x) can use the incoming value,
bound to x, with at most the capabilities allowed by the write capability of the
channel used in the communication.
The third new rule (ty-match) in Figure 3.5 takes advantage of the extra
structure of types and is particularly relevant for capability based typing systems.
However it does require some motivation. In capability based type systems, as we
have already noted, a process only receives values with some specific capabilities.
Subsequently it may receive some further capabilities on that value and it should
be able to accumulate these for future use. For example the process

inA ?(x) inB ?(y) if x = y then R1 else R2

82 Types for aPi

receives two values from the resources inA and inB , presumably with certain
capabilities. When executing the code R1 it is known that these two values are
in fact the same and therefore within R1 that actual value should be available at
both the capabilities received along inA and along inB . This is the purpose of the
rule (ty-match). It says we can assume if v1 = v2 then R1 else R2 is well-typed
relative to  if
• R2 is well-typed relative to 
• v1 and v2 have associated with them some capabilities, given by A1 and A2 respectively
• R1 is well-typed in an environment where v1 has in addition the capabilities of v2 , namely
the type A2 , and vice-versa for v2 .

The precise environment for checking R1 is obtained by adding to 

• the knowledge that v1 has the capabilities of v2 , that is adding v1 :A2

• symmetrically, adding the knowledge that v2 has the capabilities of v1 , adding v2 :A1
.

Of course this extra information may render the environment inconsistent; that is
, v1 :A2
, v2 :A1
is not a valid type environment. In this case the rule (ty-match)
cannot be successfully applied, as our type system will have a property similar to
the (sanity checks), Lemma 3.5: whenever the judgement    P can be inferred
we will be assured that    env. But for this case we have the alternative rule
(ty-mis.match), from Figure 3.10. It turns out that whenever value terms v1 and
v2 can be assigned incompatible types they can never be made identical using any
well-typed substitution. Consequently here we know that the true branch will never
be executed, and only R2 needs to be checked.

Example 3.21 [Typing the Memory Server ] Let us now reconsider the memory
server from Example 3.15, which in turn uses the memory code Mem from
Example 2.11. First let us decide on the declaration types of the get and put methods.
Since they are read by the memory and written to by clients they need to be declared
with both read and write capabilities. But the channels transmitted are only ever
used for writing. Therefore appropriate definitions are

Dg = rw w int

Dp = rw (int, w
)

If p,g is an environment that assigns put, get to Dg , Dp respectively, then it is easy

to establish
p,g  Mem
Turning now to the server memSERV its only free name is s and therefore it
should be possible to type it with respect to some simple environment s that maps
 3.4 Types as capabilities 83

s to a type of the form rw S

. Note again that we need to give s a read and write
capability; it will be read by the server and written to by clients.
However the channels transmitted on s are only ever used by the server to send
the access methods; therefore S should take the form
w (Sp , Sg )

where Sp , Sg are the types at which the server wishes clients to have access to
the put and get methods, respectively. Since it wishes to retain read capability for
itself these are released with the write capability only:
Sp = w (int, w
)

Sg = w w int

Note that these in turn allow the memory to only use the write capability on the
return channels sent via these methods.
To sum up, s assigns to s the type
rw w (w (int, w
)
, w w int

One can now check that

s  memSERV
The ability to type the client mClient depends on the declaration types of the bound
names r, a, b. Suppose we define these by
Dr = rw (Sp , Sg )

Da = rw

Db = rw int

Then one can establish the judgement

s  mClient
Note also that again these bound names must be declared with both a read and
write capability, typically the former being transmitted to the memory and the
latter exercised by the client itself.
However the important point of the example is that there is no possible type Dr
for which
s  badClient
For the sake of argument suppose Dr has the form rw Cp , Cg
; it must take this
form in order to have any chance of typing the process. Then in order to derive
s , r : Dr  r?(z, w) badMem
84 Types for aPi

it would be necessary to derive

s , r : Dr , z : Cp , w : Cg  badMem
But because of the definition of badMem this is obviously only possible if Cp is
a read capability; that is it is a subtype of some type of the form r T
. But, as we
now argue, the further constraint that s! r
be well-typed does not allow this.
The typing requirement
s , r : Dr  s! r

requires that
Dr <: S, that is rw Cp , Cg
<: w Sp , Sg

This in turn implies, among other things, that

Sp <: Cp
However the form of Sp , w . . .
– a write only capability, means that Cp cannot be
a read capability.
The essence of this example is that the type of the request channel of the memory
server ensures that clients only obtain the write capability on the put and get
methods of the newly generated memory cell. The type system ensures a capability-
based approach to programming, in which predefined access control decisions can
be enforced.

Example 3.22 [Using the Rule (ty-match) ] Consider the process OOI
(new s : rw)(outr ! s
| outw ! s
| R)
where R is the recursive process
rec x. in?(y) (if y = s then (give! gold
| x) else (give! brass
| x))
Here we use rw as an abbreviation for the type of a synchronisation channel, one
that can send and receive the empty tuple, rw ()
; in a similar manner we use r, w
to represent r ()
, w ()
respectively.
The process R accepts a value on the port in and only if this is the newly created
resource s does it give out gold; in other cases it gives out brass.
Suppose  has the following entries:
outr → rw r

outw → rw w

in → rw rw

give, spend → rw str

 3.4 Types as capabilities 85

Then it is straightforward to infer

  OOI

But is it possible to type a process that can successfully obtain the treasured gold?
The important point is that in will only accept values that have both the read and
write capabilities, and these are distributed separately via the ports outr , outw
respectively.
Let Probe be defined by

outr ?(x) outw ?(y) if x = y then ( in! x

| give?(z) spend! z
) else stop

When Probe is run in parallel with OOI the sought after gold will be spent.
Moreover
  Probe
But the rule (ty-match), from Figure 3.10, is essential to the inference. The crucial
step is the inference of

, x : r, y : w  if x = y then (in! x
| give?(z) spend! z
) else stop

Using (ty-match) this follows from

, x : r, y : w, x : w, y : r  in! x
| give?(z) print! z

Here x has the capabilities required for the typing of in! x

; we have

  in : w rw

  x : rw

where the last judgement is inferred via an instance of (ty-meet) from Figure 3.9.
It is easy to see that the rule (sty-eq), from Figure 3.5, is not sufficient to type
Probe; with this rule the capabilities on x can never be augmented to satisfy the
requirements of in.

Example 3.23 [Using the Rule (ty-mis.match) ] Suppose  is an environment such

that

a → rw int

in → rw rw bool

and consider the process P defined by

in?(x) if x = a then a! false

else stop
86 Types for aPi

Then obviously the sub-term a! false

cannot be typed with respect to .
Nevertheless we have
  P
This follows from the rule (ty-mismatch) because

, x : rw int
 x : rw int

, x : rw int
 a : rw bool

and rw int
 ↓ rw bool
.
In other words the conditional nature of (ty-match) leads to occurrences of
untyped sub-terms within well-typed processes. However these untyped sub-terms
can never be executed. One may be tempted to add an extra premise to the rule
(ty-mis.match), requiring that R1 be well-typed with respect to , despite the fact
that it will never be executed. However for the effect of this see Question 15 at the
end of the chapter.

3.4.3 Subject reduction

Despite the fact that environments may have multiple entries many of the properties
of typechecking capability types are inherited directly from Section 3.3, or are mild
generalisations thereof; but there are complications in the proofs, due both to these
multiple entries and to the presence of subtyping.
We leave it to the reader to check that the sanity checks in Lemma 3.5 remain
true. Perhaps the most important difference between the two typing systems is that
values no longer have unique types; Proposition 3.6 is obviously no longer true.
Nevertheless we now outline how an environment  can still be considered as a
function from its domain dom(), that is the set of identifiers for which it has an
entry, to types. For any u ∈ dom() let {u} be the non-empty set of types E for
which there is an entry u : E in .

Lemma 3.24 Suppose   env and u ∈ dom(). Then

(1) {u} ↓
(2)   u : ({u}).

Proof: We prove both statements simultaneously by induction on the derivation of

  env, and an analysis of the last rule used. If this is (e-empty) then the results
are true vacuously, as u cannot be in dom().
So we can assume it has the structure   , u : E and   env is inferred by one
of the rules (e-base), (e-proc) or (e-ext); as an example we consider the last.
 3.4 Types as capabilities 87

Here if u does not appear in   both required statements (1) and (2) are immediate;
for if u is in the domain of  it must be that u and u coincide, and therefore {u}
is the singleton set {E }.
So we may assume that u is in the domain of   . Then induction applied to (2)
gives    u : (  {u}), and using a simple argument on value judgements this can
be extended to
  u : (  {u}) (3.17)
Now if u is different from u then {u} is the same as   {u}; so (1) follows
by induction, and (2) coincides with (3.17). So we may assume that u = u, and
therefore that {u} =   {u} ∪ {E }.
1. As we have already seen, induction applied to (2) gives    u : (  {u}). Therefore
the side condition on the formation rule (e-ext) ensures that ((  {u})) ↓ E , which is
enough to ensure that {u} ↓ .
2. We now know from (1) that ((  {u}))  E exists, and it is easy to see that it is a greatest
lower bound for the set {u}. So we need only establish   ((  {u}))  E . But this
follows from an application of (ty-meet), to (3.17) and   u : E .

With this lemma we can now easily interpret well-formed environments as partial
functions.
Definition 3.25 (environments as partial functions) For every u in dom() let (u)
denote ({u}).
We also use  r and  w for the related partial functions for looking up the read or
write capabilities on a given identifier. For example  r (u) is only defined if (u)
is defined and has one of the forms r Tr
or rw Tw , Tr
, in which case it returns
the type Tr . We will also use the notation (u) ↓def ,  r (u) ↓def , etc. to indicate
that these partial functions are defined for a particular element, u. The properties
of these functions are pursued in Question 9. 

Thus we can consider, as with simple types in Section 3.2, an environment as

mapping identifiers in its domain to types, with many of the expected properties. For
example the second part of Lemma 3.24 may now be read as saying   u : (u)
whenever u is in the domain of .
The main properties of value typing, replacing Proposition 3.6, may now be
stated.
Proposition 3.26
(i)   u : A implies (u) exists, and (u) <: A.
(ii)   u : r T1
and   u : w T2
implies T2 <: T1 .
(iii)   V : T1 and   V : T2 implies T1  T2 exists and   V : (T1  T2 ).
(iv) (subsumption)   V : T1 and T1 <: T2 implies   V : T2 .
88 Types for aPi

Proof: First consider statement (i).   u : A means that u is in the domain of ,

and therefore by Definition 3.25 (u) exists. Moreover it is defined to be ({u}),
and so obviously (u) <: A.
The second statement is a consequence of the first. For if   u : r T1
we
are assured that (u) exists, and therefore (u) <: r T1
and (u) <: w T2
. So
(u) must have the form rw Tr , Tw
. Then the subtyping rules, and the first part of
Lemma 3.17 give the required
T2 <: Tw <: Tr <: T1
The third statement is also a corollary of the first, at least when V is a simple
identifier u. In this case (u) exists, and we know (u) <: Ti . So T1  T2 exists
and therefore   u : T1  T2 follows by an application of (ty-meet). If V is a base
value then T1 and T2 must be identical, since base values belong to only one base
type. Otherwise, when V is a vector, say (v1 , . . . , vn ), the two types T1 , T2 take the
form (A11 , . . . , An1 ), (A12 , . . . , An2 ) respectively. Here we know   vi : Ai1 , Ai2 , and
by induction we obtain   vi : (Ai1  Ai2 ), and an application of (ty-tup) gives
  (v1 , . . . , vn ) : (A11  A12 , . . . , An1  An2 ). But this amounts to the required   V :
(T1 T2 ), since by definition (A11 , . . . , An1 )(A12 , . . . , An2 ) = (A11 A12 , . . . , An1 An2 ).
The proof of the final statement is a simple induction on the derivation of  
V : T1 , with the base case being provided by the rule (ty-sub) from Figure 3.9.

Now let us reconsider the properties in Proposition 3.8. These can be generalised
by lifting the subtyping relation to environments:
Definition 3.27 (comparing environments) For valid type environments let 1 <:
2 if 2  u : E implies 1  u : E. 

This makes the set of all type environments into a pre-order, and it is worth noting
that it is not a partial order. For example with
1 = c : r int
, c : w int
and 2 = c : rw int

we have 1 <: 2 and 2 <: 1 although they are different. We will write 1 ≡ 2
to mean that both 1 <: 2 and 2 <: 1 are true; we say the environments 1
and 2 are equivalent.
Proposition 3.28 (weakening) Suppose   <: . Then
•   V : T implies    V : T
•   R implies    R.

Proof: By induction on the derivations of   V : T and   R respectively,

and an analysis of the last rule applied. So the proof is similar to (weakening) in
Proposition 3.8, but there are more cases. Here we examine two instances.
 3.4 Types as capabilities 89

As a first example suppose   (new n : D) R, because of an application of

(ty-new) to , n : D  R. Again we can assume that n is fresh to both  and   .
It is therefore easy to check that   , n : D is also a well-defined environment, and
that , n : D <:   , n : D. So we can apply induction to obtain   , n : D  R1 from
which the required    (new n : D) R follows by (ty-new).
As a second example suppose   if v1 = v2 then R1 else R2 because of an
application of (ty-match) to

(1)   v1 : A1
(2)   v2 : A2
(3)   R2
(4) , v1 :A2
, v2 :A1
 R1 .

We can apply induction to the first three statements to obtain

(1’)    v1 : A1
(2’)    v2 : A2
(3’)    R2 .

Now suppose that   , v1 :A2

, v2 :A1
happens to be a valid environment. Then it
is dominated by , v1 :A2
, v2 :A1
and so we can also apply induction to (iv) to
obtain

(4’)   , v1 :A2
, v2 :A1
 R1

and then the required result will follow by an application of (ty-match).

So the possibility remains that   , v1 :A2
, v2 :A1
is not a valid environment. In
fact the third part of Proposition 3.26 ensures that this can only happen when v1 is
different from v2 . An analysis of the environment construction rules, in Figure 3.8
will reveal that this is only possible if a type A exists such that either

(a)    v1 : A and A  ↓ A2 or
(b)    v2 : A and A  ↓ A1 .

But in both cases we have enough information to apply (ty-mis.match) to obtain

the required result    if v1 = v2 then R1 else R2 .

It is worth pointing out that this proof of (weakening) does not rely on the
property (interchange), unlike the corresponding proof for simple types, that of
Proposition 3.8.
This last result says that equivalent environments are equally powerful, from
the point of view of typechecking. Despite not using (interchange) in the previous
90 Types for aPi

proof it remains true in this new typechecking system, and provides an important
example of equivalent environments:
Lemma 3.29 (interchange) Suppose 1 , u : E, u : E , 2  env. Then
• 1 , u : E , u : E, 2  env
• 1 , u : E, u : E , 2 ≡ 1 , u : E , u : E, 2 .

Proof: See Question 8 at the end of the chapter.

Note that the more restricted version of (interchange) used in Proposition 3.7 is an
immediate corollary of the two results we have just given. Finally (strengthening)
from Proposition 3.8 also remains true. The proof we give here relies on
(interchange), but a more general version may be found in Question 12.
Proposition 3.30 (strengthening)
• , u : E  V : T implies   V : T, provided u does not occur in V .
• , u : E  R implies   R, provided u does not occur in R.

Proof: In each case the proof proceeds by induction on the derivation involved,
and a case analysis on the last rule used in the derivation. Let us consider a typical
case, for the second statement, when R has the form if v1 = v2 then R1 else R2
and the rule used is (ty-match). Then we have
(1) , u : E  v1 : A1 , v2 : A2
(2) , u : E  R2
(3) , u : E, v1 :A2
, v2 :A1
 R1 .

Since v1 and v2 cannot be u, the corresponding result for value judgements, and
induction, give
(1’)   v1 : A1 , v2 : A2
(2’)   R2 .

A number of applications of (interchange), from the previous lemma, gives

, u : E, v1 :A2
, v2 :A1
≡ , v1 :A2
, v2 :A1
, u : E
So (3) can be replaced by
(3’) , v1 :A2
, v2 :A1
, u : E  R1

to which induction can be applied to obtain

(3”) , v1 :A2
, v2 :A1
 R1 .

Now (ty-match), applied to (1’), (2’), (3”) gives the required result.

 3.4 Types as capabilities 91

At this stage we have developed for capability types all of the properties of the proof
inference system that underlie both the substitution result and subject reduction for
simple types.
Theorem 3.31 (subject reduction for capability types) Suppose   P and P −→
Q. Then   Q.
Proof: As in the case of simple types subject reduction relies essentially
on developing corresponding substitution results, along the lines of those in
Proposition 3.9, the main one being:
  v : A and , x : A  R implies   R{|v/x|} (3.18)
However despite having accumulated all the necessary properties used in the proof
of Proposition 3.9, these are not sufficient to establish (3.18) for capability types.
With simple types, the proof of (3.18) in the case when R has the form if v1 =
v2 then R1 else R2 is handled in a straightforward manner by induction, because of
the purely inductive nature of the corresponding typing rule, (sty-eq) in Figure 3.5.
With capability types the corresponding rule, (ty-match) in Figure 3.10 is more
complicated, and it turns out we need to formulate a more general substitution result
than (3.18).
We refrain from doing so here. The details will be spelt out in a more sophisticated
setting in Chapter 5; see the proof of Proposition 5.31. However having established
(3.18), the proof of subject reduction itself is a minor extension to the proof of the
corresponding result for simple types, Theorem 3.12; again the details are spelt out
in the more sophisticated setting of Chapter 5, in Theorem 5.34.
For those wishing to complete the theorem directly for typed aPi, see Question 17
at the end of the chapter.

Instead let us look at some examples that re-enforce the various requirements we
have made on the subtyping relation for capability types.
Example 3.32 [Contra-variance of Write ] We work with an environment 1 such
that 1 (a) = rw rw
, 1 (c) = r, where, as in Example 3.22, rw, r stand for
rw ()
, r ()
respectively. Note rw <: r.
Suppose on the contrary we allowed subtyping to be co-variant on write
capabilities, with the rule
T1 <: T2
(3.19)
w T1
<: w T2

So we would have w rw
<: w r
. Note that this would allow us to infer
  a! c

92 Types for aPi

because of the rule (ty-sub), in Figure 3.9. This spells trouble; a reader on a, with
type rw rw
, may be expecting a value with both read and write capabilities, while
c, in the environment 1 , has only the read capability. Such a reader is defined by
a?(y) (y? | y!)
With (3.19) it would be straightforward to infer
1  a! c
| a?(y) (y? | y!)
Yet
a! c
| a?(y) (y? | y!) −→ c? | c!
and 1   c? | c!.

Example 3.33 [Constraint on Read Write/Types ] Here we show that the constraint
Tw <: Tr is required when forming the type rw Tr , Tw
in Figure 3.7. Suppose this
were dropped. Then F = rw rw, r
would be a valid type and
2  a! c
| a?(y) (new b : F)(b! y
| b?(x) x! | x?)
where 2 is such that 2 (a) and 2 (c) are rw r
, r respectively. Here again trouble
brews; c is sent on channel a, which only transmits read capabilities. It is passed
through b, which can magically fabricate new capabilities. We have
a! c
| a?(y) (new b : F)(b! y
| b?(x) x! | x?) −→∗ (new b : F)(c! | c?)
and this latter process cannot be typed by 2 .

Example 3.34 [Co-variance of Read ] Now suppose we demanded that subtyping

was contra-variant in read; that is we had the typing rule
T1 <: T2
r T2
<: r T1

Then we would have r r

<: r rw
, thereby allowing the inference of
2  a?(y) (y? | y!)
again because of the rule (ty-in) and (ty-sub). This now leads to a failure of
subject reduction because 2   c? | c! while
2  a! c
| a?(y) (y? | y!)
and
a! c
| a?(y) (y? | y!) −→ c? | c!

We started this chapter by remarking that a type checking system is best justified
by a clear definition of the runtime errors it eliminates. But for the type system
 3.5 Questions 93

in Figure 3.10 we have no corresponding definition of runtime error. For example

we have managed to show that badClient cannot be typechecked, relative to s ,
but we have no formal statement of what exactly badClient violates. Intuitively
it receives the methods get, put, with a restricted set of capabilities and seeks to
use them with capabilities it has not been granted. But what exactly does it mean
to receive a value with a set of capabilities? Or for a process to use a value at a
capability it has not been granted ? Similarly with the counter-examples to subject
reduction just discussed in Example 3.33. There is some reasonable sense in which
they misuse granted capabilities but this misuse has not been elaborated.
This can be formalised, using a tagged version of aPi, where each occurrence
of a value is tagged according to the capabilities with which it can be exercised.
The tags on a value are then changed during transmission in accordance with the
type of the transmitting channel. However the formalisation is non-trivial and is
postponed until Section 5.4.

3.5 Questions
1. Prove   R implies   R.
s

2. Prove the following more general form of (strengthening) for simple types:
(i) , u : E,   s env implies ,   s env.
(ii) If , u : E,   s V : T where u does not occur in V , then ,   s V : T.
(iii) If , u : E,   s R where u does not occur free in R, then ,   s R.
Your proof should not rely on (interchange), Proposition 3.7.
3. Show that the processes memSERV, mClient and badClient from Example 3.15 can
all be typed relative to some simple type environment, as defined in Section 3.2. You
should also instantiate the declaration types used by these processes with simple types.
4. Show that   (new n : D) R implies that D has to be a channel type.
5. Suppose A, <
is a partially complete pre-order.
• Prove that S ↓ implies S has a greatest lower bound, whenever S is a finite non-empty
subset of A.
• Prove a similar result for upper bounds; that is, providing S is finite and non-empty,
S ↑ implies S has a least upper bound.
• Show that if a and b are both greatest lower bounds for a subset S of A then a < b
and b < a.
6. Prove the following inversion properties of subtyping:
(i) For any base type, T <: base implies T = base.
(ii) If S <: (T1 , . . . Tn ) then S = (S1 , . . . , Sn ), where Si <: Ti .
(iii) If S <: r Tr
then
• either S = r Sr
, where Sr <: Tr
• or S = rw Sr , Sw
, where Sr <: Tr .
94 Types for aPi

(iv) If S <: w Tw
then
• either S = w Sw
, where Tw <: Sw
• or S = rw Sr , Sw
, where Tw <: Sw .
(v) If S <: rw Tr , Tw
then S = rw Sr , Tw
, where Sr <: Tr and Tw <: Sr .
7. In a similar vein show how the structure of T is determined by that of S, whenever
S <: T.
8. (Interchange) for capability types. Prove that 1 , u : E, u : E , 2  env implies
(i) 1 , u : E , u : E, 2  env
(ii) 1 , u : E, u : E , 2 ≡ 1 , u : E , u : E, 2 .
9. Suppose u is in the domain of the capability type environment . Prove
(i)   u : r Tr
implies  r (u) is defined and  r (u) <: Tr
(ii)   u : w Tw
implies  w (u) is defined and Tw <:  r (u).
10. Let A, <
be a partially complete pre-order. S ⊆ A is said to be pairwise consistent if
a ↓ b for every pair a, b ∈ S.
(i) Prove that in Types, <:
, every finite non-empty pairwise consistent subset of
Types has a greatest lower bound.
(ii) Is this true for an arbitrary partially complete pre-order?
11. Suppose σ is a mapping over Names ∪ Vars that maps names to names and variables
to variables. For such a σ let σ be the type association list obtained by replacing each
u : E in  by σ (u) : E.
Assuming σ is injective on the domain of , prove:
(i)   ty implies σ  ty
(ii)   V : T implies σ  σ (V ) : T
(iii)   R implies σ  Rσ .
Show that these are not generally true when σ is not injective.
12. Without using (interchange) prove the following more general form of (strengthening):
, u : E,    R implies ,    R, whenever u does not occur in R.
13. Let Typesps be the subset of capability types of the form r Tr
, w Tw
or rw T
. Show
that the pre-order Typesps , <:
is not partially complete.
14. Show that well-defined type environments are not necessarily preserved by well-typed
substitutions. That is, if   v : A then , {|v/x|}  env does not necessarily follow
from , x; A,   env.
15. Suppose we replace the rule (ty-mis.match) with
(ty-mis.match.bis)
  v1 : A1 , v2 : A2
  R1 : proc
  R2 : proc
A1  ↓ A2
  if v1 = v2 then R1 else R2 : proc
Show that subject reduction no longer holds for the revised typing system.
 3.5 Questions 95

16. Without using (interchange) prove the following substitution property for the capability
typechecking system: suppose   v : A and x is new to , and , {|v/x|}  env. Then
, x : A,   R implies , {|v/x|}  R{|v/x|}.
17. Use the result of the previous question to prove Theorem 3.31, subject reduction for
capability types. There should be no need to use (interchange).
 4
Types and behaviour in aPi

One component of the behavioural equivalences in Chapter 2 is the ability of users

to interact with processes. We have just developed, in Chapter 3, a capability-based
view of processes, where interaction depends on knowledge of these capabilities;
moreover these capabilities can change over time. Thus the behaviour of processes,
or the perceived behaviour from a user’s point of view, depends on current
capabilities. The purpose of this chapter is to modify the behavioural theories of
Chapter 2 so as to take these capabilities into account.
As a simple illustration consider the memory server memSERV of Example 2.11,
which was typed in Example 3.21 using the environment s ; this maps the entry
point to the server, s, to the type rw S
. The ability of a client to use this server
depends on it having the output capability, w S
, on the channel s. If Client is a
process that does not have this capability then the server effectively behaves like
the empty process stop, from Client’s point of view.
The client’s point of view is captured by a type environment, say client , which
encapsulates its capabilities. So what we need is a form of behavioural equivalence
parameterised on type environments,

 |= P ≈ Q (4.1)

indicating that P and Q are equivalent from the point of view of any user typeable
by . Then if client is such that client   s : w S
we would expect

client |= memSERV ≈ stop (4.2)

Moreover we would like to be able to reason using the following compositionality

principle:

from   R and  |= P ≈ Q it follows that  |= R | P ≈ R | Q (4.3)

96
 Types and behaviour in aPi 97

Using this principle we would then be able to deduce from client  Client and
(4.2) above that

client |= Client | memSERV ≈ Client (4.4)

under the reasonable assumption that the parameterised equivalence, as yet

undefined, satisfies the general property  |= P ≈ P | stop, whenever   P.
This statement, (4.4), would then be a formalisation of the fact that the server
cannot be used by the client, whenever client  s : w S
.
In this chapter we will restrict our interest to bisimulation equivalence,
developing a version of it parameterised on type environments, representing the
context’s capabilities on the available resources. However before embarking on
this, it is worthwhile to develop more intuition about the intent of the judgements
of the form (4.1) above. Intuitively the type environment  constrains both the
processes being observed, P and Q, and the surrounding environment, the context,
or processes trying to use, or observe, P and Q. Unfortunately, because capabilities
can be generated dynamically, the type environment of the observed processes, and
that of the observing processes may diverge.

Example 4.1 Consider the two processes

P ⇐ (new c : rw)(a! c
| c?P  )
Q ⇐ (new c : rw)(a! c
| stop)

and suppose that they are typeable with respect to an environment  whose only
entry for a is rw r
; in other words, a can only be used to transmit channel names
that themselves in turn can only be used for at most read access.
We would expect
 |= P ≈ Q
because no observing process can exercise the c?P  component of P. This follows
since the observing process can only gain knowledge of the new channel c by
receiving it on the channel a; but this method of transmission ensures that it can
never obtain write access on c, because of the type of a in , and therefore can
never activate the c?P  component.
More importantly this example demonstrates that the observing environment
can evolve to be different from that of the observed processes. Here, after the
transmission of c on a, the residuals of the observed processes P and Q are working
in an environment in which c has both read and write capabilities, while the
observing environment only has write access. If we call the former i , the internal
environment, and the latter e , the external environment, we have in this example
i <: e .

98 Types and behaviour in aPi

Life can get even more complicated; situations may arise in which the external
environment knows more than the internal environment.
Example 4.2 Consider the two processes
P ⇐ a(x)?R1
Q ⇐ a(x)?R2
and an observer trying to decide on the judgement
 |= P ≈ Q
where  allows a to read/write identifiers with write capability only. Here, a priori,
 is both the internal and external environment.
As part of the investigation an observer may generate a completely new name
n, new to , with both read and write capabilities, and transmit it along a to the
observed processes, P and Q. The result now is that the external environment has
n with both read and write capabilities, while the internal environment only has it
with the write capability. We have e <: i .

These two examples indicate that to be completely general we need to develop
a theory of judgements of the form
e ; i |= P ≈ Q
where e and i are two consistent type environments constraining the observing
and the observed respectively. This is a rather daunting prospect. Instead we make
a choice and we make a choice to use one environment only. Moreover this lies
somewhere between e and i . We develop judgements of the form
I |= P ≈ Q (4.5)
where I is a type environment representing the observer’s current knowledge of
the declared capabilities of P and Q. We ignore everything else in the observer’s
environment, while the internal type environment i , will remain implicit; it will
periodically play a role. When making judgements of the form (4.5) it will for the
most part be assumed that there is some, unspecified, type environment i that
types P and Q. Moreover by careful development of the theory we will be able to
assume i <: I ; that is, despite Example 4.2, the observer’s knowledge is always
contained in that of the observed.

4.1 Actions-in-context for API

Here we revisit the ideas of Section 2.3 to develop an lts for typed aPi. The
ability of a process P to perform actions is constrained by a type environment I ,
 4.1 Actions-in-context for aPi 99

representing the current capabilities a user has of the channels of P. Following

the above discussion we change our focus from processes to configurations. These
consist of processes paired with type environments, representing an observer’s
current knowledge.

Definition 4.3 (configurations) A configuration is a pair

I P

where P is a process from typed aPi and I is a type environment such that i  P
for some other type environment i such that i <: I ; we say I is compatible with
i . Since P is a closed term we can assume that both i and I do not contain any
variables. 

Thus we define the judgements, called actions-in-context, which take the form
µ
I  P −→ I   P  (4.6)

where I  P and I   P  are both configurations. Intuitively this indicates that

• P has the ability to perform the typed action µ, an input, output or internal move as
described in Section 2.3
• the knowledge I allows the environment to participate in this action.

Thus, for example, if µ is an output on a channel a then I requires the input

capability on a. Note that actions-in-context may change not only the process
performing them but also the user’s knowledge. For example an output action
may increase the user’s knowledge, by either sending new names or sending new
capabilities on known names. The typed action labels µ can take one of three
forms:
αi = (c̃ : D̃)a?V : The input of the value V along the channel a, which contains the new
names (c̃), declared by the observer at the types (D̃). These labels are only defined
when a does not occur in (c̃), which in turn is a distinct sequence of names; we
also insist that all these bound names ci have to appear somewhere in the imported
value V .
αo = (c̃ : D̃)a!V : the output of the value V along the channel a, simultaneously exporting
the new names in the set (c̃). Again this label is only defined if the names (c̃) are all
distinct, different from a, and we insist that all the bound names ci appear somewhere
in the exported value V . These new names are declared by the observed process at
the types (D̃).
µ = τ : this indicates, as usual, some internal activity, and should more or less coincide
with the reduction semantics.
100 Types and behaviour in aPi

Figure 4.1 External actions-in-context for typed aPi

Notation 4.4
• We will use the complementary notation, µ introduced briefly in the proof of
Proposition 2.21, on these actions; as usual τ is τ itself, while (c̃ : D̃)a?V is (c̃ : D̃)a!V ,
and (c̃ : D̃)a!V is (c̃ : D̃)a?V .
• If µ is an external action, (c̃ : D̃)a!V or (c̃ : D̃)a?V , then (c̃) are the bound names of µ,
denoted bn(µ), while ch(µ) denotes the channel used in µ, namely a.
• As in Notation 2.12 we use αi , αo to range over all valid input and output labels
respectively.

The rules for generating these judgements are formally defined in Figure 4.1, for
the input and output actions, and in Figure 4.2 for internal actions. The first rule,
(l-in), allows the process a?(X ) R to input the value V , assuming the environment
 4.1 Actions-in-context for aPi 101

Figure 4.2 Internal actions-in-context for typed aPi

has write permission on the channel a, that is the type I w (a) is defined, and the
value V is already known to the environment at a type suitable to be sent on a,
that is I  V : I w (a); as indicated in Definition 3.25, we use I w (a)↓def to say
that the partial function I w is defined for a. The next rule, (l-weak), allows the
environment to invent new names to send to the observed process. For example
suppose n is a fresh name. Then this rule means
(n:D)a?n
I  a?(x) R −−−−→ I , n : D  R{|n/x|}
for any type D satisfying D <: I w (a), because
a?n
I , n : D  a?(x) R −→ I , n : D  R{|n/x|}
can be inferred from (l-in). Note that there are implicit side conditions in the rule
(l-weak), enforced by insisting that the rule can only be applied when the action
label in question, (n : D)αi is well-formed. For example if αi is (c̃ : D̃)a?V , in
order for the action label (n : D)αi to be well-defined, n must be different from
a and all the names in (c̃), and it must appear somewhere in V . So the rule can
only be applied in these circumstances. The explicit side-condition, that n be fresh,
might be automatically inferred from Barendregt’s principle but just to be safe we
mention it as part of the rule.
There are also two rules governing output. If I has read capability on the channel
a then (l-out) allows the process a! V
to output the value V on a; moreover the
observer obtains on V the capabilities determined by its read capabilities on a.
The extra knowledge gained is captured by extending the type environment with
V :I r (a)
. Note that the fact that I  a! V
is a configuration ensures that the
augmented association list, I , V :I r (a)
, is a valid environment; see Question 3 at
the end of the chapter.
The second output rule, (l-open), allows the observed process to export new
names. For example suppose the channel a is known to the environment as one
102 Types and behaviour in aPi

from which values may be read at some type Cr , that is I r (a) is Cr . Then (l-open)
allows us to deduce
(b:D)a!b
I  (new b : D)(a! b
| b?(x) R) −−−−→ I , b : Cr  stop |b?(x) R

because (l-out) gives

a!b
I  a! b
| b?(x) R −→ I , b : Cr  stop |b?(x) R

Note that the observer gains the new name b not at the declaration type D but at
its read type on the export channel a, namely Cr . Barendregt’s convention ensures
that b does not occur in I and therefore this action represents the export of a new
name to the environment.
Also, as with (l-weak), the rule (l-open) has extra implicit side-conditions. If
αo is the label (c̃ : D̃)a!V , then to ensure that the resulting label is well-defined n
must be different from a and all of (c̃), and must occur somewhere in V ; in addition
Barendregt’s convention ensures that n does not occur in I .
Finally in Figure 4.1 there is a straightforward contextual rule, with some explicit
side-conditions to ensure the proper functioning of free and bound names.
The rules for internal actions-in-context, in Figure 4.2 are also for the most part
straightforward; (l-rec), (l-eq) and (l-neq) are all borrowed from the reduction
semantics in Figure 2.4. So we concentrate on explaining the communication rule
(l-comm). Intuitively a τ action represents some internal communication, which
is therefore independent of the ability of an observer to see it happen. However to
make the definition of actions-in-context inductive in character we need to define
these in terms of observable input and output actions-in-context. For this reason, in
(l-comm) we allow the input and complementary output actions to occur relative
to arbitrary knowledge environments, I1 and I2 respectively. Note however that
in the conclusion the observer’s environment I does not change after the internal
action has occurred. This is in agreement with the intuition that internal actions are
independent of the observer; the rule is constructed so that if a process can perform
a τ action-in-context with respect to some environment I it can do so with respect
to any environment; see Corollary 4.13. Note also that the sender and receiver do
not a priori have to agree on the declaration types of the newly generated channels.
Finally let us point out that there are some alternative formulations we could
have used in the presentation of these rules. For example instead of (l-in) we could
have:
(l-in )
I  a : w T
I  V :T
a?V
I  a?(X ) R −−→ I  R{|V/X |}
 4.1 Actions-in-context for aPi 103

However this is an equivalent rule. For I  a : w T

if and only if I w (a) exists and
T <: I w (a); this means that if I  V : T and I  a : w T
then I  V : I w (a).
Similarly instead of (l-out) we could have
(l-out )
I  a : r T

a!V
I  a! V
−
−→ I , V :T
 stop
This of course implies (l-out) as the type T may be chosen to be I r (a) but in
general allows many more actions to be derivable. However the extra actions
are not of great interest as they simply consist in exporting V at supertypes
of I r (a).
The remainder of this section is devoted to a detailed analysis of actions-in-
context, and their properties. For example, although we have given rules for the
deducing actions-in-context (4.6) as of yet we have no guarantee that the residual
I   P  is a valid configuration, even if I  P is; indeed we need to develop a
considerable number of consistency results about these judgements before being
able to prove so. In order to give the material some structure we divide it into
three convenient subsections. Throughout these it will be very convenient to have
a simple criteria for ensuring that an extension of a valid environment is again a
valid environment; if I  env, when can we be sure that I , V :T
is also a valid
environment? A sufficient condition is given in the following:

Lemma 4.5 Suppose  <: I are two valid environments, and (ñ) are fresh names.
Then , ñ:D̃
 V : T implies I , V :T
 env.

Proof: See Question 2 at the end of the chapter.

4.1.1 The role of type environments

The most significant aspect of actions-in-context (4.6) is that the resulting
knowledge of the environment, I  is completely determined by the initial
knowledge, I , and the action µ.

Definition 4.6 (action residuals) The partial function after from type environments
and typed action labels to type environments is defined as follows:
• I after τ is always defined to be I
• if µ is the input label (c̃ : D̃)a?V then I after µ is always defined to be I, c̃:D̃
, where
each ci is new to I
• if µ is the output label (c̃ : D̃)a!V then I after µ is defined to be I, V :I r (a)
, whenever
this is a valid environment; again here we assume that each ci is new to I. 
104 Types and behaviour in aPi
µ
Proposition 4.7 Suppose I  P −→ I   P  is an action-in-context. Then (I after µ)
is a well-defined environment and coincides with I  .
µ
Proof: By induction on the inference of I  P −→ I   P  , and an examination
of the last rule used. Note that we can ignore the case when µ is τ , as the result is
trivial.
As an example suppose the last rule used is (l-out). Then I  a! V
is a
configuration and I r (a) ↓def ; we have to show that I , V :I r (a)
 env. This
will follow from Lemma 4.5 if we can find a valid type environment  <: I such
that   V : I r (a).
Since I  a! V
is a configuration we know there is some type environment
i <: I such that i  a! V
; this is the required . For we know there is some
type T such that i  V : T and i  a : w T
. Also i <: I implies that i  a :
r I r (a)
. So from part (ii) of Proposition 3.26 we have that T <: ir (a). Therefore
(subsumption) from the same proposition gives the required i  V : I r (a).
All other cases are considerably simpler, and left to the reader.

It is worth emphasising that the new environment after an action is actually

independent of the process being observed. If
µ
I  P −→ I1  P 
µ
I  Q −→ I2  Q

then I1 is the same as I2 ; they both coincide with I after µ.

Notation 4.8 To emphasise the determinacy of the effect of actions-in-context on

the environment’s knowledge, in future we often abbreviate
µ
I  P −→ (I after µ)  O

to simply
µ
I  P −→ Q
µ
Further we will write P −→ Q to mean that there exists some I such that
µ
I  P −→ Q.

µ
The notation P −→ Q may seem like odd notation but it simply indicates that P,
under the right external circumstances, has the ability to perform the action µ. The
right external circumstances, necessary to allow the action µ to happen, is also
easy to define.
 4.1 Actions-in-context for aPi 105

Definition 4.9 (allowing actions) We define the partial predicate allows between
environments and action labels as follows:
• I allows τ is always true
• I allows (c̃ : D̃)a?V is true whenever I w (a) is defined and I, c̃:D̃
 V : I w (a)
• I allows (c̃ : D̃)a!V is true whenever I r (a) is defined.

As usual here, as we view ci as bound variables, the implicit assumption is that they
are new to I . 

The next result states that if a process P has the ability to perform an action and
the environment I allows the action to happen, then the action can occur in the
configuration I  P:
µ
Proposition 4.10 Suppose I1  P −
→ Q. Then
• I1 allows µ
µ
• if I2 allows µ then I2  P −
→ Q, whenever I2  P is a configuration.

Proof: The first result is again a simple proof by induction on the derivation of the
µ
judgement I1  P −→ Q. So we concentrate on the second. Suppose
µ
I1  P −→ Q (4.7)

We show that I2 allows µ enables us to transform the derivation of (4.7) into a

µ
derivation of I2  P −→ Q. The proof proceeds by induction on the derivation
of (4.7). We examine some of the more interesting cases; note that the case when
(l-comm) is used is trivial.

• Suppose (4.7) is inferred using (l-in). This case is straightforward. We know µ has
the simple form a?V , and the hypothesis, I2 allows µ, means that I2w (a) is defined
and I2  V : I2w (a) is precisely the premise required to apply (l-in) to obtain the
required
µ
I2  P −→ Q

• Suppose (4.7) is inferred using (l-out). Here µ has the form a!V , P is a! V
and
the hypothesis is that I2r (a) is defined. The crucial point here is that I  a! V
is a
configuration, and we repeat the argument already used in the proof of Proposition 4.7.
There is a type environment i <: I such that i  a! V
. From the former we can
deduce that i  a : r I r (a)
, and from the latter we have i  a : w T
for some T such
that i  V : T. The second part of Proposition 3.26 ensures that T <: I r (a), and then
(subsumption) gives i  V : I r (a). Once more Lemma 4.5 ensures that I, V :I r (a)

is a valid type environment. This means that (l-out) can be applied to deduce the
required
µ
I2  P −→ Q
106 Types and behaviour in aPi

• All of the inductive cases are straightforward. We examine one instance, when (4.7) is
inferred using (l-weak). Here µ has the form (n : D)αi where αi is an input action label
(c̃ : D̃)a?V and the action has the form
µ
I1  P −→ Q

because
αi
I1 , n : D  P −→ Q (4.8)
The hypothesis, I2 allows µ unravels to the assumption that I2w (a) is defined and I2 , n :
D, c̃:D̃
 V : I2w (a).
We turn this hypothesis into a statement about the environment (I2 , n : D). Since the
action label is well-defined n must be different from a and so (I2 , n : D)w (a) is exactly
the same as I2w (a). In other words we have that (I2 , n : D)w (a) is well-defined and
(I2 , n : D), c̃:D̃
 V : (I2 , n : D)w (a); that is (I2 , n : D) allows αi . So we can apply
induction to (4.8) to obtain
αi
I2 , n : D  P −→ Q
An application of (l-weak) now gives the required conclusion.

µ
The fact that the derivation of the actions-in-context I  P −→ Q depends
on specific information present in I means that they are preserved by various
manipulations on I . We give two examples in the next result.

Lemma 4.11 (sanity checks)

µ µ
(Weakening): Suppose I  P − →P  . Then Im <: I implies Im  P −
→P  , whenever
Im  P is a configuration.
µ
(Fresh strengthening): Suppose I , n : D  P − → P  , where n does not occur in the
µ
action label µ. If I  P is a configuration then I  P − → P.
µ
Proof: Weakening is proved by derivation induction on I  P −→ P  . The type
environment is only used in two rules, (l-in) and (l-out), where Im can be used in
place of I . For example suppose the derivation is a result of an application of the
a?V
rule (l-in); that is I  a?(X ) R −
−→ R{|V/X |} because I w (a)↓def and I  V : I w (a).
Since Im <: I this means that Imw (a) is also defined. Moreover the contra-variance
of w −
means that I w (a) <: Imw (a) and by (weakening) in the type system, and
(subsumption) we therefore have Im  V : Imw (a). So we have established the two
a?V
premises necessary to derive Im  a?(X ) R − −→ R{|V/X |} via an application of (l-in).
Fresh strengthening is a simple corollary of the previous result, Proposition 4.10.
For if n does not appear in µ then one can show that (I , n : D) allows µ implies
I allows µ. In the input case this inference relies on both (interchange) and
(strengthening) for the typing system, Proposition 3.7 and Proposition 3.30.

 4.1 Actions-in-context for aPi 107

4.1.2 Subject reduction

We would expect, in analogy with Theorem 3.31 for the reduction semantics, that
internal moves preserve well-typing:
τ
  P and I  P −→ P  implies   P (4.9)
However, unlike the reduction semantics, internal moves are defined in terms of
input and output actions and therefore we have to develop appropriate results on how
these interact with well-typedness. Unfortunately, because the environments used
to type processes in actions-in-context are implicit, the statement of these results
is somewhat complex. Even worse these implicit environments play a limited role
in the proof of (4.9). For although we know there is some i <: I such that
i  P, a priori there need be no relationship between the implicit i and the
explicit .
µ
Theorem 4.12 (subject reduction) Suppose I  P −
→ Q and   P.
• If µ is τ then   Q.
• If µ is an output action then  w (ch(µ)))↓def and ( after µ)  Q, V :  w (a).
• If µ is the input action then  r (ch(µ))↓def and ( after µ)  env implies ( after µ)  Q.

Proof: The proof is by induction on the derivation of the judgement

µ
I  P −→ P  (4.10)
and analysis of the last rule used.
Suppose it is the axiom (l-in). So the action is
a?V
I  a?(X ) R −
−→ I  R{|V/X |}
The typing rule (ty-in) from Figure 3.10 gives some Tr such that   a : r Tr

and , X :Tr
 R; the former gives our first requirement, that  r (a)↓def .
Here ( after µ) unravels to , V : r (a)
and so let us assume that this is a
well-defined environment. Since  r (a) <: Tr this means ( after µ)  V : Tr .
Then by (weakening) we have  after µ, X :Tr
 R and so the substitution
result, Proposition 3.9 adapted to capability types, gives the required  after
µ  R{|V/X |}.
Suppose (l-out) is the last rule used in the derivation of (4.10). So the action is
a!V
I  a! V
−
−→ I , V :I r (a)
 stop
The typing rule (ty-out) from Figure 3.10 gives a type Tw such that   a :
w Tw
, V : Tw ; again the first part implies  w (a)↓def . Here ( after µ) is simply 
and the contra-variance of w −
, together with the second part of Proposition 3.26,
therefore gives ( after µ)  V :  w (a), and we are finished, since trivially
( after µ)  stop.
108 Types and behaviour in aPi

Suppose (4.10) is inferred using (l-comm). Here we have

τ
I  P | Q −→ I  (new c̃ : D̃)(P  | Q )

because

(c̃:D̃ )a?V
I1  P −−−−−→ I1  P 
(c̃:D̃)a!V
(4.11)
−−−−→ I2  Q
and I2  Q −

for some I1 , I2 . From   P | Q we have to prove   (new c̃ : D̃)(P  | Q ); in

fact we establish , c̃:D̃
 P  | Q .
We can apply induction to the input and output moves in (4.11) because our
assumption means   P and   Q. The output move gives

  a : w  w (a)

, c̃:D
 Q , V :  w (a)

while the input move gives

  a : r  r (a)

, V : r (a)
 P  , provided , V : r (a)
 env

So it remains to show that , c̃:D̃

 P  . Note that the fact that the types of the
bound names in the input and output actions in (4.11) may be different has not
hindered the progress of the proof.
By Proposition 3.26 we know that  w (a) <:  r (a) and therefore that , c̃:D

V :  r (a); by Lemma 4.5 this is sufficient to ensure that , V : r (a)
is a well-
defined environment. Moreover this means that , c̃:D
<: , V : r (a)
and the
required typing of P  therefore follows by (weakening), Proposition 3.28.
The remaining axioms, (l-rec), (l-eq) and (l-neq) are straightforward, as is
the inductive case (l-ctxt). This leaves (l-open) and (l-weak) to consider; we
examine the latter and leave the former to the reader. So we have
(b:Dc̃:D̃)a?V
−−−−−−→ I   Q
I P−

because
(c̃:D̃)a?V
−−−−→ I   Q
I, b : D  P − (4.12)
The inductive hypothesis applied to (4.12) gives the existence of (I , b : D)r (a).
But since a and b must be different this must coincide with I r (a).
Now suppose , V :I r (a)
is a well-defined environment. Once more, since
I (a) coincides with (I , b : D)r (a), we can apply the inductive hypothesis to
r

(4.12) to obtain the required , V :I r (a)

 Q.

 4.1 Actions-in-context for aPi 109

Subject reduction will be a particularly useful tool when developing further

properties of actions-in-context. Our first example is to show that these are actually
defined over configurations.
µ
→ I   Q. Then I   Q
Corollary 4.13 Suppose I  P is a configuration and I  P −
is also a configuration.
Proof: We know that some i exists, with i <: I , such that i  P; and that
I  is (I after µ). We must find a type environment i <: (I after µ) such that
i  Q. If µ is the internal action τ then the required i is obviously i itself, from
subject reduction. Otherwise it is i , c̃:D̃
, where (c̃ : D̃) are the newly created
names in µ.
To see this first suppose µ is the output action (c̃ : D̃)a!V . Then subject reduction
gives (i after µ)  Q, that is i , c̃:D̃
 Q, which is one of our requirements. We
also have to show i , c̃:D̃
<: I after µ, that is i , c̃:D̃
<: I , V :I r (a)
.
From the fact that i <: I one can show that iw (a) <: I r (a). Moreover by
subject reduction we also have i , c̃:D̃
 V : iw (a), which via (subsumption)
gives i , c̃:D̃
 V : I r (a). The required i , c̃:D̃
<: I after µ now follows by
an application of Lemma 4.5.
On the other hand if µ is the input label (c̃ : D̃)a?V then (I after µ) is I , c̃:D̃

and obviously i , c̃:D̃

<: I , c̃:D̃
. But we have to establish
i , c̃:D̃
 Q (4.13)
To do so we use the fact that I allows µ is well-defined, which unravels to
I , c̃:D̃
 V : I w (a). Since I w (a) <:  w (a) <:  r (a), and i <: I this means
i , c̃:D̃
 V : ir (a). This is enough to ensure that i afterµ  env, and therefore by
subject reduction, that i after µ  Q. Since i , c̃:D̃
<: (i after µ) (weakening)
gives the required (4.13).

4.1.3 Relation with reduction semantics

Let us now check that the notion of internal movement engendered by actions-in-
context coincides, more or less, with the reduction semantics of typed aPi; we need
a typed version of Corollary 2.16. As in Section 2.3 we tackle this incrementally;
indeed the arguments we use are only typed versions of those employed in that
section. But first we need some more auxiliary results about the use of knowledge
in actions-in-context.
Let us first show that actions-in-context are preserved by structural equivalence.
µ
→ P  . Then there is
Proposition 4.14 In typed aPi suppose P ≡ Q and I  P −
   µ 
some Q such that P ≡ Q and I  Q − →Q.
110 Types and behaviour in aPi

Proof: This is a generalisation of Lemma 2.13 and the proof is an equally

tedious argument by induction on the proof that P ≡ Q. The inductive cases
are straightforward, as are most of the axioms; the only difficulty is the axiom
(s-extr), when P, Q have the form (new n : D)(P1 | P2 ), P1 | (new n : D) P2
respectively, or visa-versa, and n is not free in P1 . As an example let us outline how
an action-in-context
µ
I  P1 | (new n : D) P2 −→ R
can be matched by a corresponding action from (new n : D)(P1 | P2 ).
One possibility is that P1 is responsible for the move, that is it has the form
µ
I  P1 | (new n : D) P2 −→ P1 | (new n : D) P2
µ
because I  P1 −→ P1 . In this case we know that n cannot appear in µ and therefore
the required matching move is
µ
I  (new n : D)(P1 | P2 ) −→ (new n : D)(P1 | P2 )
which can be inferred from (l-cxt).
The second possibility is that (new n : D) P2 is responsible for the move. Here
the argument is equally straightforward, although it depends on whether n appears
in the label µ.
The final possibility is that µ is the internal label τ and the move is a
communication between P1 and (new n : D) P2 . Here again there are two cases,
when a value is sent by P1 or received by P1 . Let us consider the latter, which is
the more interesting. So the move is of the form
τ
I  P1 | (new n : D) P2 −→ (new c̃ : D̃)(P1 | P2 )
because
αi
I1  P1 −→ P1
αo
I2  (new n : D)(P2 ) −→ P2
for some environments I1 , I2 ; moreover we can assume αo is an output label,
(c̃ : D̃)a!V , and therefore αi is some corresponding input label.
There are now two cases, depending on whether n is exported in αo . If it is then
let us suppose (c̃ : D̃) has the form (n : D)(d̃ : D̃ ), αo has the form (n : D)βo
and the output move must have been inferred by (l-open); the more general case
is treated in a similar manner. So we must have
I2  P2 −β→
o
P2 (4.14)
The corresponding input label has the form (n : D )βi and the input move must
have been inferred by the rule (l-weak). So we have
βi
I1 , n : D  P1 −→ P1
 4.1 Actions-in-context for aPi 111

The rule (l-comm) can therefore be applied to give

τ
I  P1 | P2 −→ (new d̃ : D̃ )(P1 | P2 )

Then an application of (l-ctxt), gives the required matching move

τ
I  (new n : D)(P1 | P2 ) −→ (new c̃ : D̃)(P1 | P2 )

The second case, when n is not exported in αo is much more straightforward; P2
must have the form (new n : D) P2 and the output move must have been inferred
using (l-ctxt) from
αo
I2  P2 −→ P2

The required matching move may therefore be found by applying (l-com) to this
move and the corresponding input rule above, followed by an application of the
second part of (l-ctxt).

From this it is straightforward to show that reductions can be captured, up to

structural equivalence, by actions-in-context.

τ
Corollary 4.15 Suppose I  P is a configuration and P −→ Q. Then I  P −
→ Q
for some Q ≡ Q.

Proof: By induction on the inference of P −→ Q. The inductive case, when

(r-struct) is used, is catered for by the previous lemma and the only interesting
axiom is (r-comm):

c! V
| c?(X ) R −→ R{|V/X |}

Since I  c! V
|c?(X ) R is a configuration we know that there is some environment
i compatible with I such that i  c! V
| c?(X ) R. This type judgement provides
enough information to establish the premises to applications of the rules (l-out)
and (l-in) from Figure 4.1, to conclude ensure that
c!V
i  c! V
−→ stop
c?V
i  c?(X ) R −
−→ R{|V/X |}

respectively. An application of (l-comm) from Figure 4.2 then gives the required
τ
I  c! V
| c?(X ) R −→ stop |R{|V/X |}

112 Types and behaviour in aPi

The converse result requires, as in Proposition 2.15, an analysis of precise syntactic

structure of actions-in-context.
Proposition 4.16 In typed aPi:
(c̃:D̃)a! V

• if I  P −−−−−→ Q then P is structurally equivalent to (new c̃ : D̃)(a! V

| Q)
(c̃:D̃)a?V
−−−−→Q then P is structurally equivalent to a term of the form (new ñ : D̃ )(P  |
• if I P −
a?(X ) R), where no ni appear in V , and Q is structurally equivalent to (new ñ : D̃)(P  |
R{|V/X |})
τ
• I P− → I  Q implies P −→ Q.

Proof: A straightforward proof by induction on the derivation of the actions-

in-context; the details are very similar to the proof of the corresponding result
in the untyped case, Proposition 2.15.

Putting these two results together we get the natural generalisation of

Corollary 2.16 to the typed case.
Corollary 4.17 Suppose I  P is a configuration. Then P −→ Q if and only if
τ
I P− → Q for some Q such that Q ≡ Q .

4.2 Typed bisimulation equivalence

We have now in place all the requirements to define an lts for typed aPi, and
thereby induce a version of bisimulation equivalence. However there is a problem;
the actions-in-context of the previous section induce an equivalence that is much too
intensional to capture any reasonable adaptation of the touchstone equivalence = ∼
to a typed setting.
Example 4.18 Let P, Q denote the processes
(new n : rw) (new m : rw) a! m, n
(new m : w) (new n : r) a! m, n

respectively. Assuming some Ia that knows about the channel a at the type
rw (w, r)
, the configurations Ia  P and Ia  Q can perform different output
actions, labelled
(n : rw, m : rw)a!(m, n) (m : w, n : r)a!(m, n)
respectively. So a bisimulation equivalence based on these actions would
distinguish them.
However one can argue that no reasonable observer, constrained by the type
environment I , would be able to distinguish between these two processes. Both
deliver a new name on the channel a, and that is it. So although we have not yet
reformulated =∼ to take types into account, any reasonable formulation would result
in P and Q being considered indistinguishable.

 4.2 Typed bisimulation equivalence 113

Basically the output actions, labelled with the declaration types of new channels,
are much too intensional.

4.2.1 The definition

First let us define a slightly more abstract version of the output actions-in-context.

Definition 4.19 (untyped output actions-in-context) For any set of names {c̃} we
write
(c̃)a!V
I P−−−→ I   Q
(c̃:D̃)a!V 
if there is some collection of types (D̃) such that I  P −
−−−−→ I  Q. As with all
action labels we make no distinction between the order in the bound names (c̃). 

Note that the various properties of actions-in-context developed in the previous

section still apply to these less intensional actions. For example the definition of
action residuals, Definition 4.6, still applies; if µ is an output action label then
(I after µ) is independent of any types occurring in µ. Formally let un(µ) denote
the function that leaves the label µ untouched unless it is an output label, in which
case it removes the type information. Furthermore we write µ ∼ µ to mean
un(µ) = un(µ ), that is µ and µ are the same labels, except possibly for the types
at which new names are exported. Then

µ ∼ µ implies (I after µ) = (I after µ)

(I allows µ) if and only if (I allows µ )

Similarly with the predicate I allows µ, Definition 4.9; so the determinacy of

the change in the environment, Proposition 4.7, remains true when applied to
these actions. However applications of subject reduction, Theorem 4.12, require
knowledge of the types at which new names are exported. Indeed the main reason
for recording these was to allow us to formulate correctly the actions-in-context;
the rule (l-comm) makes essential use of them.

Definition 4.20 (lts for typed aPi) This is defined as follows:

• the states consist of configurations I  P
µ
• the next state relations are the judgements of the form I  P −→ I  Q, where µ can
take the form
– τ , for internal actions
– (c̃ : D̃)a?V , for input actions
– (c̃)a!V , for output actions.
114 Types and behaviour in aPi

We let ≈bis denote the standard bisimulation equivalence in the resulting lts; thus
this is now a relation between configurations, rather than, as in Chapter 2, between
processes. 
Example 4.21 Let us revisit Example 4.1 and the two processes
P1 ⇐ (new c : rw)(a! c
| c?P  )
P2 ⇐ (new c : rw)(a! c
| stop)
As in the previous example, let Ia denote some type environment in which Ia (a) =
rw r
, and let us assume that Ia  P1 and Ia  P2 are both configurations. To show
Ia  P1 ≈bis Ia  P2
we need to exhibit a bisimulation R containing the pair Ia  P1 , Ia  P2
.
Let P1 , P2 denote the processes (stop |c?P  ), (stop | stop) respectively and
Iac denote the type environment Ia , c : r. Then the required R consists of
Ia  P1 ↔ Ia  P2
Iac  P1 ↔ Iac  P2
This is easy to check as the only actions-in-context that can be performed by these
configurations are
(c)a!c
−−→ Iac  P1
Ia  P1 −
(c)a!c
−−→ Iac  P2
Ia  P2 −


Although in principle a bisimulation R may relate arbitrary configurations we will
only ever use them to relate configurations with identical knowledge environments.
A convenient way of specifying such restricted bisimulations is by defining a family
of relations R over processes, parameterised by type environments I , with the
property that whenever P, Q
∈ RI then both I  P and I  Q are configurations.
In this formulation we use the more suggestive notation
I |= P R Q (4.15)
to denote the fact that P RI Q, for a particular environment I .
Because of Proposition 4.7, the transfer property for bisimulations then amounts
to demanding that whenever (4.15) above holds then every action-in-context
µ
I  P −→ P 
must be matched by an action
µ̂
I  Q =⇒ Q (4.16)
 4.2 Typed bisimulation equivalence 115

for some Q and µ , such that µ ∼ µ and

(I after µ) |= P  R Q

If we can show that each individual relation RI in the family, and its inverse, has
this parameterised transfer property, then we know from (4.15) that I  P≈bis I  Q;
continuing with our more suggestive notation we will write this as

I |= P ≈bis Q

It is worth emphasising that such a statement automatically means I  P and I  Q

are both valid configurations.
This view of bisimulation relations also emphasises that many of the standard
techniques can also be applied in this parameterised setting. For example, now
viewing a bisimulation as a family of relations of the form (4.15) above, it is
straightforward to check that each individual component is an equivalence relation
over processes. Moreover, because of Proposition 4.14, in the transfer property it
is sufficient to find a Q as in (4.16) above, but satisfying the weaker condition that

(I after µ) |= P  R Q

for some Q structurally equivalent to Q . In other words the technique of

bisimulation equivalence up to structural equivalence, given in Definition 2.18,
generalises smoothly to the typed case. We refrain from spelling out the details;
instead see Question 8 at the end of the chapter. But the technique will be used in
some proofs, such as that of Proposition 4.24 below.
We finish this section with a brief look at the role of the knowledge environment
I , this time in the judgements

I |= P ≈bis Q (4.17)

Our results will largely depend on the (sanity checks) in Lemma 4.11. One would
not expect this relation to be preserved by increasing the environment’s knowledge
I . That is if Im <: I then one would not expect (4.17) to imply Im |= P ≈bis Q.
Example 4.21 provides an instance. With Ia (a) = rw r
we have

Ia |= (new c : rw)(a! c
| c?P  ) ≈bis (new c : rw)(a! c
| stop)

but if the knowledge is increased to Im <: Ia , with Im (a) = rw rw

, we have

Im |= (new c : rw)(a! c
| c?P  )  ≈bis (new c : rw)(a! c
| stop)

It is more reasonable to expect that restricting the environments knowledge does

not affect the equivalence of processes.
116 Types and behaviour in aPi

Proposition 4.22 (strengthening for bisimulation equivalence) Suppose I <: Il .

Then I |= P ≈bis Q implies Il |= P ≈bis Q.

Proof: Let the family R be defined by letting

I |= P R Q

whenever Im |= P ≈bis Q for some Im <: I . We show that this is a bisimulation;

note that we are assured both I  P and I  Q are both configurations.
µ
Suppose I |= P R Q and I  P −→P  . We must find a matching action-in-context,
µ̂
I  Q =⇒ Q , where µ ∼ µ such that (I after µ) |= P  R Q .
Since I |= P R Q we know Im |= P ≈bis Q for some Im <: I . Moreover
µ
(weakening) from Lemma 4.11 gives the action-in-context Im  P −→ P  . So there
is a matching action-in-context
µ̂
Im  Q =⇒ Q (4.18)

such that Im after µ |= P  ≈bis Q .

The existence of (Im after µ) also ensures that (I after µ) is well-defined, and
moreover (Im after µ) <: (I after µ); see Question 4 at the end of the chapter.
µ
In other words I after µ |= P  R Q . Finally the existence of I  P −→ P 
means that (I allows µ ) and therefore the second part of Proposition 4.10 can
be applied to (4.18), to obtain the required matching move with the restricted
µ̂
environment I  Q =⇒ Q .

An obvious consequence of this result is that rearranging the knowledge I to an

equivalent environment I  has no effect on equivalences; that is I |= P ≈bis Q and
I ≡ I  implies I  |= P ≈bis Q.
There is a partial converse to this (strengthening) result; the environment’s
knowledge can be increased by inventing new names, without affecting the
equivalences.

Proposition 4.23 (fresh weakening for bisimulation equivalence) Let n be fresh to

I , P, Q. Then I |= P ≈bis Q implies I , n : C |= P ≈bis Q.

Proof: Let the family of relations R be defined by letting

I |= P R Q

if I ≡ I1 , n : C, for some n fresh to I1 , P and Q, where I1 |= P ≈bis Q. We show

that this family of relations generates a bisimulation.
Suppose I |= P R Q and
µ
I  P −→ P  (4.19)
 4.2 Typed bisimulation equivalence 117

We must find a corresponding action-in-context

µ̂
I  Q =⇒ Q

where µ ∼ µ , such that (I after µ) |= P  R Q .

By the definition of R we know that I ≡ I1 , n : C and I1 |= P ≈bis Q. Since n
cannot appear in the label µ, (fresh strengthening) from Lemma 4.11 can be applied
µ
to (4.19) to give the action-in-context I1  P −→ P  , which we can therefore match
µ̂
with I1  Q =⇒ Q such that (I1 after µ) |= P  ≈bis Q .
µ̂
(Weakening), again from Lemma 4.11, transforms this action into I  Q =⇒ Q ,
which is the required corresponding move to (4.19) above. For

(I after µ) |= P  R Q (4.20)

follows because one can calculate that (I afterµ) ≡ (I1 afterµ), n : C. For example
if µ is the output action (c̃ : C̃)a!V then (I after µ) ≡ (I1 , n : C), V :I r (a)
.
But because of the freshness of n, I r (a) coincides with I1r (a), and so this latter
environment is equivalent to (I1 , V :I1r (a)
), n : C, that is (I1 after µ), n : C.

4.2.2 Compositionality
We wish to establish the compositionality principle (4.3) for bisimulation
equivalence:

from   Q and  |= P1 ≈bis P2 it follows that  |= P1 | Q ≈bis P2 | Q

(4.21)
The idea is to mimic the proof of the corresponding result in the untyped setting,
Proposition 2.21. There we needed the ability to decompose an internal action from
the compound process P | Q into the contributions from the individual processes
P and Q, and conversely, the ability to compose appropriate contributions from P
and Q back into an internal action from P | Q. For untyped actions this more or less
τ
follows by the inductive definition of −→ but here we have to deal with the more
subtle actions-in-context; in particular with the presence of changing environments
when internal actions are decomposed and subsequently recomposed.
Before embarking on the proof it is worthwhile considering in some detail the
reason why the straightforward approach used in Proposition 2.21 does not work.
Using this we would define the least family of relations R satisfying
(i) I |= P1 ≈bis P2 implies I |= P1 R P2
(ii) I |= P1 R P2 implies I |= P1 | Q R P2 | Q whenever I  Q
(iii) I, n : D |= P1 R P2 implies I |= (new n : D) P1 R (new n : D) P2
(iv) I |= P1 R P2 and n fresh to I implies I, n : D |= P1 R P2
118 Types and behaviour in aPi

and show that the result generates a bisimulation. There are at least two problems
here.
The first is exemplified by Example 4.18. We will never be able to show that
Ia |= (new n : rw) a! n
R (new n : r) a! n
(4.22)
The third clause in the definition of R only allows the same binding to be applied to
related processes. Although (4.22) is not a direct instance of the compositionality
principle it will arise in an analysis of the case when Q, in (4.21) above, is b?(x) a! x

and P1 , P2 are (new n : rw) b! n

, (new n : r) b! n
respectively.
An even worse inadequacy is seen by reconsidering Example 4.21. Referring to
the definitions there we will never be able to establish
Ia |= (new c : rw)(a! c
| c?P  ) R (new c : rw)(a! c
| stop) (4.23)
This could only be inferred from
Ia , c : rw |= a! c
| c?P  R a! c
| stop
that would require
Ia , c : rw |= c?P  R stop
that will not follow from the proposed definition of R. Again (4.23) above is not
a direct instance of the compositionality principle, but it will arise, for example,
when analysing the case when Q is (new c : rw) b! c
and P1 , P2 are b?(x) (a! x
|
x?P  ), b?(x) (a! x
| stop) respectively.
The definition of R needs to be more sophisticated; in particular we need a
more general form of the condition (iii) above, which will allow us to close related
processes using scoped names with different declaration types.
Proposition 4.24 (compositionality) Suppose I  Q. Then I |= P1 ≈bis P2 implies
I |= P1 | Q ≈bis P2 | Q.
Proof: In this proof, for convenience, we will not distinguish between sequences
of bindings, c̃:C̃
and type environments, allowing meta-variables for the latter to
appear in process terms.
Let R be the family of relations defined by
I |= (new 0 )(P1 | Q) R (new 0 )(P2 | Q)
whenever there exist type associations I0 , ,  such that
• I is compatible with both  and 
• I, I0 is compatible with both , 0 and  , 0
• , 0  P1 and  , 0  P2
• I, I0 |= P1 ≈bis P2 and I, I0  Q.
 4.2 Typed bisimulation equivalence 119

We show that R generates a bisimulation, up to structural equivalence, from which

the result will follow.
Note that (4.22) and (4.23) are accommodated within this definition, at least up
to structural equivalence. For example in the former case we can have

Ia |= (new n : rw)(a! n
| stop) R (new n : r)(a! n
| stop)

because Ia , n : r |= a! n
≈bis a! n
.
Since each relation RI is symmetric it is sufficient to show how each action-in-
context from the left-hand side
µ
I  (new 0 )(P1 | Q) −→ T (4.24)

can be matched, up to structural induction, by one from the right-hand side. First
consider the case when this is an external action, say an output (c̃ : D̃)a!V ; the case
of input is similar but more straightforward. This action must be the responsibility
of either P1 or Q, and again we look at the more complicated case, the former. So
(4.24) must take the form
µ
I  (new 0 )(P1 | Q) −→ (new l )(P1 | Q)

In turn this must be derived using a sequence of applications of (l-open) or the

second part of (l-ctxt), from Figure 4.1, and one application of the first part of
(l-ctxt), to
α
I  P1 −→ P1 (4.25)
Here the label α is obtained from µ by stripping off any binding (n : D) used in an
application of (l-open). (In the input case, only (l-ctxt) is used and α coincides
with µ.) We may apply (weakening) from Lemma 4.11 to this action, to obtain
α
I , I0  P1 −→ P1 (4.26)

Now using the hypothesis

I , I0 |= P1 ≈bis P2
we obtain a matching action-in-context


α
I , I0  P2 =⇒ P2 (4.27)

such that
(I , I0 ) after α |= P1 ≈bis P2
Furthermore from (4.25) we know I allows α  , and so Proposition 4.10 enables
us to obtain


α
I  P2 =⇒ P2 (4.28)
120 Types and behaviour in aPi

from which we can reconstruct


µ
I  (new 0 )(P2 | Q) =⇒ (new r )(P2 | Q)
This reconstruction uses the same sequence of applications of the rules (l-open)
and (l-ctxt) as used in the inference of the original move (4.24) from (4.25).
To prove that this is the required move to match (4.24), we have to establish
(I after µ) |= (new l )(P1 | Q) R (new r )(P2 | Q)
However this is easily achieved; (I after µ) unravels to I , V :I r (a)
, which
is equivalent to an environment of the form (I after µ), I0 , where I0 is an
extension of I0 . So the type associations required in the definition of R are I0 ,
and (, c̃:D̃
), ( , c̃:D̃
) where (D̃ ) are the declaration types of the exported
names in the matching action µ ; subject reduction, Theorem 4.12, is useful when
checking this.
Now consider the case when the action-in-context we are trying to match, (4.24)
is internal. So it must take the form
τ
I  (new 0 )(P1 | Q) −→ (new 0 , 1 )(P1 | Q ) (4.29)
If this derives from either Q or P1 then we can proceed as before. So let us
assume that it is the result of some communication between Q and P1 ; in other
words (4.29) is derived using an application of the rule (l-comm) in Figure 4.2,
followed of course by a sequence of applications of (l-ctxt). There are two
possibilities.
Output from P1 to Q: Here we have an output label αo = (c̃ : D̃)a!V and
αo
(i) Ir  P1 −→ P1
αo
(ii) Il  Q −→ Q
(iii) 1 = c̃:D̃

for some environments Ir , Il . However since (I , I0 )allowsαo , Proposition 4.10

gives
αo
(i’) I, I0  P1 −→ P1 .
We now use the hypothesis
I , I0 |= P1 ≈bis P2
to obtain a matching action-in-context
(c̃:D̃ )a!V
I , I0  P2 =====⇒ P2 (4.30)
such that
(I , I0 ) after (c̃ : D̃ )a!V |= P1 ≈bis P2
 4.2 Typed bisimulation equivalence 121

Note that here the types of the exported names, (D̃ ), need not coincide with
those in αo . But this is irrelevant as a lookup of Definition 4.6 gives
(I , I0 ) after (c̃ : D̃ )a!V = (I , I0 ) after α
that is the form I , I0 , I1 .
An application of (l-comm) to the moves (4.30) and (ii) above, followed by
numerous applications of (l-ctxt) now gives, up to structural equivalence,
τ
I  (new 0 )(P2 | Q) =⇒ (new 0 , 1 )(P2 | Q )
where 1 represents the environment c̃:D̃
.
One can then check that this is the required matching move since we have
accumulated all the information necessary to establish
I |= (new 0 , 1 )(P1 | Q ) R (new 0 , 1 )(P2 | Q )
To see this note that (I , I0 ) after α has the form I , I0 , I0 and so in this case we
can take the typed associations required in the definition of R to be (I0 , I0 ) and
the original  and  respectively. Then by subject reduction, Theorem 4.12,
we have
• , 0 , 1  P1 and , 0 , 1  P2
• (I, I0 ) after α  Q , since we know (I, I0 )  Q
and the required compatibilities between the various type environments are easily
seen to be true.
Output from Q to P 1 : This case is similar, consisting first of a decomposition of
the move into the contributions from Q and P1 , finding a match to the latter from
P2 and a recomposition to obtain an internal move. The details are marginally
simpler as the types of the imported names do not change.

This result gives a very powerful proof principle for reasoning about bisimulation
equivalence ≈bis in a typed setting. Let us return to the discussion of Example 3.21
at the beginning of this chapter, and show that the results we have developed do
indeed support the informal reasoning outlined there. First note that it is trivial to
establish
client |= memSERV ≈bis stop
as the relation
client  memSERV ↔ client  stop
is a bisimulation; neither configuration can perform any action in context. Also
since client  Client the compositionality principle immediately gives
client |= Client | memSERV ≈bis Client | stop
122 Types and behaviour in aPi

It is also straightforward to show that

client |= Client | stop ≈bis Client

and therefore conclude

client |= Client | memSERV ≈bis Client

What we hope this chapter has demonstrated is that standard bisimulation theory
can be adapted to our version of aPi with capability types. But of course the
critique of bisimulation equivalence given in Section 2.5 applies equally well
in the presence of types. To what extent is typed bisimulation equivalence an
appropriate behavioural equivalence for typed aPi?
It is possible to develop a typed version of reduction barbed congruence, from
Section 2.5, and the inadequacies of bisimulation equivalence with respect to this
touchstone equivalence demonstrated there carry over to the typed case. However
we can also develop a typed version of asynchronous bisimulations to overcome
these inadequacies. But we postpone this discussion until Section 6.7, where it is
examined in a distributed setting.

4.3 Questions
µ
1. Suppose I  P −→ I   P  .
(i) If µ is the input label a?V , prove
• fn(P  ) ⊆ fn(P) ∪ n(V ).
(ii) If µ is the output label (c̃ : D̃)a!V , prove
• fn(P  ) ⊆ fn(P) ∪ bn(c̃)
• n(V ) ⊆ fn(P) ∪ bn(c̃).
(iii) If µ is τ then fn(P  ) ⊆ fn(P).
2. Suppose 1 , 2 are two valid capability type environments, such that 1 <: 2 , and
suppose that (ñ) are fresh. Prove
(i) 1 , ñ:D̃
 V : T implies 2 , V :T
 env
(ii) 1 , ñ:D̃
<: (2 , V :T
).
3. Use Question 2 to prove that if I  a! V
is a valid configuration and I r (a)↓def , then
I, V :I r (a)
is also a valid configuration.
This means that when the rule (l-out) from Figure 4.1 is applied to a valid configuration,
the conclusion is also a valid configuration.
4. Suppose Im <: I, where (Im after µ) is defined, and I allows µ. Prove that
(i) (I after µ) is also defined
(ii) (Im after µ) <: (I after µ).
 4.3 Questions 123

5. Suppose Im <: I. Which of the following statements are true:

(i) I allows µ implies Im allows µ
(ii) Im allows µ implies I allows µ?
6. Prove that bisimulation eqivalence is still an equivalence relation in the typed setting.
Specifically, prove
• I |= P ≈bis P for all processes P
• I |= P ≈bis Q implies I |= Q ≈bis P
• I |= P ≈bis Q and I |= Q ≈bis R implies I |= P ≈bis R.
7. Suppose I  P is a valid configuration. Prove I |= P ≡ Q implies I |= P ≈bis Q.
8. Let R be a family of relations over typed aPi processes such that every component R
µ
and its inverse satisfies

the following transfer property: if I |= P R Q then I  P −→ P 
µ̂
implies I  Q =⇒ Q for some Q and µ , such that µ ∼ µ and

(I after µ) |= P  R Q

for some Q ≡ Q . Prove I |= P R Q implies I |= P ≈bis Q.

9. Suppose that I  (new c : D) P and I  (new c : D) Q are both configurations. Prove
I |= (new c : D) P ≈bis (new c : D) Q whenever I |= P ≈bis Q.
10. Give a definition of typed asynchonous bisimulation equivalence, I |= P ≈a Q, by
adapting the rules in Figure 2.6 to give actions in context
µ  
I  P −→ a I P

With your definition prove

(i) (Compositionality) I |= P1 ≈a P2 and I  Q implies I |= P1 | Q ≈a P2 | Q
(ii) I |= P1 ≈bis P2 implies I |= P1 ≈a P2 .
11. Let aPii be the language aPi augmented by the operator !P. The lts semantics for the
operator is given by
(l-iter)
µ
P −→ P 
µ
!P −→ P  |!P
while the typing is handled by
(ty-iter)
  P : proc
  !P : proc
(i) Prove I |= !P ≈bis rec x. (P | x), whenever I  P is a configuration.
(ii) Suppose R contains no occurrence of the recursion operator rec, and I  rec x. R
is a valid configuration. Then show that some process P in aPii exists, containing
no occurrence of recursion, such that I |= rec x. R ≈bis P.
 5
A distributed asynchronous pi-calculus

In this chapter we develop a language aDpi for describing explicitly distributed

computations. The new concept is that of location, site or domain, an environment
for computational activity. Intuitively a domain hosts local resources that mobile
agents use to interact with each other. Thus a typical domain can be pictured as:

Here Aga and Agb represent two mobile agents currently residing at the domain l
that contains the three local resources, r1, r2 and r3 that they may use to interact.
A distributed system may then be viewed as a collection of these independent
domains. A typical example, consisting of three domains named s, k and l, is
given in Figure 5.1. Here there are five agents distributed through the domains,
Sa, Sb, A, R, S, and five local resources, a, b at domain s, e at k and c, d at l.
We use aPi to describe these mobile agents, although we require a new primitive
to enable migration between domains. Thus we augment aPi with the construct
goto l.P
If the agent goto l.P is currently residing at k it can migrate to the domain l and
continue there with the execution of P.
To keep the language basic we have an extremely primitive notion of local
resource, simply locally declared channels; thus throughout this chapter we will use
resource and channel interchangeably. Then an agent currently residing at domain l
may use the channels declared locally at l to communicate; referring to the diagram
above, these would be channels named r1, r2 and r3. When an agent migrates to

124
 A distributed asynchronous pi-calculus 125

Figure 5.1 A distributed system

another domain k these resources at l are no longer available for it to use; of course
it may subsequently migrate back from k to l and then they become available once
more. More sophisticated notions of local resource need to be programmed in terms
of these local channels. For example if the domain l wishes to offer a service for
testing primality, as described in Example 2.10 then it would declare a local channel
called inp , start the agent primeS running locally, and distribute to its clients the
write capability only on its local channel inp . Retaining the read capability on the
local inp ensures the integrity of the service.
Also for simplicity we assume that the structure of domains is flat, that is there are
no subdomains. However domains can be declared dynamically and knowledge of
domains may be transmitted between agents along channels. Since the language is
typed we need to introduce a new class of types for locations. These types describe
the resources available at a location, together with the types at which the resources
may be used. Thus the general form of a location type is
loc[c1 : C1 , c2 : C2 , . . . , cn : Cn ], n ≥ 0
If the name of a domain is received at this type then any one of the channels c1 , . . . , cn
located there may be exercised with the associated capabilities C1 , . . . , Cn . For
example a domain named m to be used to host a memory cell, along the lines of
that described in Example 2.11, could be declared with the type
loc[put : rw Cp
, get : rw Cg
, kill : rw Ck
] (5.1)
where Cp , Cg , Ck represent the capabilities allowed on the values transmitted by
the located channels put, get, kill. The domain m could have in permanent residence
126 A distributed asynchronous pi-calculus

an agent whose task would be to service calls on these resources; this agent would
be defined as an elaboration on Example 2.11.
Knowledge of m may now be distributed via supertypes of the declaration
type (5.1) above. The general rule determining the supertype relation over location
types is given by
loc[c1 : C1 , c2 : C2 , . . . , ck : Ck , . . . , cn : Cn ] <: loc[c1 : C1 , c2 : C2 , . . . , ck : Ck ]
where k ≤ n and Ci <: Ci for each i between 1 and k. Thus an agent may know only
a subset of the resources available at a domain, and may have limited capabilities
at these resources. So, for example, the name m of the domain hosting the memory
cell could be distributed at the type
loc[put : w Cp
, get : w Cg
] (5.2)
to the clients of the memory, and at the type
loc[put : r Cp
, get : r Cg
, kill : rw Ck
]
to the manager.
Individual resources or channels at a domain m may also be transmitted between
agents. However in aDpi it is important to realise that all channels are located. Thus
in general they are represented by compound names of the form
c @k
where k is the name of a domain and c is the name of a resource located there. So,
for example, when a client sends a reply channel to a memory cell, the name of
this reply channel is now a compound name, r @k, representing the channel named
r located at the domain k. Of course the use of these compound values in turn leads
to a new kind of type, that of located channel types.
The ability of channels to transmit compound names means that we have to
extend the definition of transmission types, the types at which values may be sent
and received, to include appropriate types for these structured values. Since domain
names may also be transmitted, we must also include location types. For example a
manager of a suite of memory cells, distributed throughout various domains, may
maintain a broadcasting agent that informs clients of available cells. At a particular
point in time this agent could contain the code
. . . outcl ! mi
. . .
where mi is a domain hosting a cell. The declaration type of the channel outcl would
now be of the form rw M
, where M represents the type (5.2) above.
A priori sorting out the exact nature of what values may be transmitted, and
how, looks complicated. However we show that an extension of the type system
 5.1 The language aDpi 127

of Section 3.4 can be used in a natural manner to control the behaviour of agents.
In effect these types enable system designers to specify access control policies for
domains.
The elaboration of the language aDpi and its associated type system is the
subject of this chapter. Later, in the following chapter, we will also see that a
typed behavioural equivalence can be developed for the resulting typed language,
and moreover this can be justified contextually.

5.1 The language ADPI

The explicitly typed language aDpi is obtained by adding one further syntactic
category, called Systems, to those of aPi, or more accurately to the typed version of
aPi of Chapter 3. However we postpone the discussion of the types until the next
section.
A system is now essentially a set of located processes or agents, possibly sharing,
as in aPi, private or local names. A typical system looks like
l
P1  | (new e : D)(k
Q | l
P2 )
Here we have three located processes, or agents, P1 running at location l, Q running
at location k and P2 also running at location l. These latter two share a common
resource e of type D.
The syntax of aDpi is given in Figure 5.2, with the new syntactic categories
highlighted in bold. The simplest system, apart from the empty one 0, takes the
form l
P , consisting of essentially an aPi process P running at location l. These
located agents may be combined using the parallel constructor − | −, and the
new name constructor (new e : D)(−). It is important to note that there is not a
direct connection between this formal syntax for systems and the informal pictorial
representations, as in Figure 5.1. The latter emphasises the locality of the agents,
while the former allows agents to be grouped together in an arbitrary manner. So, for
example, if we ignore for a moment the declaration of the various local resources,
the system in Figure 5.1 may be represented by any of the terms
s
Sa | Sb | k
R | A | l
S
s
Sb | k
R | k
A | l
S | s
Sa
s
Sa | l
S | s
Sb | k
R | A
However, as we will see, all of these will be structurally equivalent.
The syntax for processes or agents is inherited directly from aPi, with one major
addition. There is the input and output of values as before, although now the values
transmitted may be compound. The more general syntax for such values, and their
128 A distributed asynchronous pi-calculus

Figure 5.2 Syntax for aDpi

related patterns, is given in Figure 5.3, with the extra forms in bold. Recall that
we tend to use the meta-variable u to denote identifiers, that is, either names or
variables; in this chapter we will sometimes refer to these as simple identifiers and
simple names. Also for the sake of clarity we tend to use a, b, c, . . . for (simple)
names in Names that are used as channels, while (simple) names such as k, l, . . .
will be used for locations. However this is an informal arrangement; formally the
role of each name in a system will be determined by the type environment for that
system.
The major addition to the syntax for processes is the construct for migration.
Intuitively
goto k.P
running at any location l will migrate to location k where the code P is launched.
To make things clear, but perhaps at the price of verbosity, we have isolated the
two kinds of names that can be declared by agents:
local channels: The agent (newc c : Dc ) P creates a new local channel named c
and then executes the code P. In a well-typed system Dc will be a local channel
type.
locations: Similarly the agent (newloc k : Dk ) P creates a new location k of type
Dk and then launches the code P.
We will sometimes use the generic syntax (new n : D) P, when the exact nature of
the name being declared is not important to the discussion at hand.
 5.1 The language aDpi 129

Figure 5.3 Patterns and values in aDpi

The constructs for the testing of identifiers, parallel composition and recursion
are as before, in aPi.
Example 5.1 [A Distributed Compute Server] Let us reconsider Example 2.10 in
which a service of testing for primality is considered. In aDpi this service has to be
located in some domain, say s, and therefore takes the form
s
DprimeS
where DprimeS is the agent maintaining the service. This agent requires an address
to which the result is to be returned and in aDpi this means both a location and a
channel at that location. In other words the agent needs to be sent
• the value to be tested, an integer
• and a located resource name c@h, an address, where the result is to be sent.

Thus we may define the servicing agent as

DprimeS ⇐ rec z. inp ?(x, y@w) (z | goto w.y! isprime(x)
)
It receives a value, bound to x, and a compound name consisting of a reply channel,
bound to y, located at a domain, bound to w. The required result is calculated, the
computation of which we are ignoring by representing it by the predicate isprime,
and then an agent is sent to the received location w to deliver it, at the reply channel
y located there. To emphasise the fact that the computation is carried out at the
server site this could be rendered as
DprimeS ⇐ rec z. inp ?(x, y@w) (z | let a = isprime(x) in goto w.y! a
)
130 A distributed asynchronous pi-calculus

if, as already suggested in Section 2.2, the language were augmented with a
construct let x = e1 in e2 for explicitly sequencing computations.
A client generates a new reply channel at its current location, sends an agent to
the service domain with the required information and awaits a reply. Thus this takes
the form
h
Client(v)
where the agent Client(v) is defined by

(newc r : Dr ) (r?(x) print! x

| goto s.inp ! v, r @h
)

The delivery of data at an address occurs so frequently in aDpi that it is worthwhile

to introduce a shorthand notation.

Notation 5.2 We abbreviate the agent goto l.c! V

to l.c! V
. We also inherit the
various notations, introduced for aPi, such as abbreviating c!
to c!, etc. Moreover
types will sometimes be omitted from terms when they play no role in the discussion.

Example 5.3 [Distributed Forwarders ] In a distributed setting a forwarder,

based on that of Example 2.9, requires two addresses, located names b@k1 , c@k2
between which it is to maintain the forwarding service. It can be defined by
h
DisF(k1 , b, k2 , c), where the code is given by

DisF(k1 , b, k2 , c) ⇐ goto k1 .
rec z. b?(x, y) goto k2 .(new ack)(c! x, ack
| ack?goto k1 .(y! | z))

The agent first goes to the source site k1 and installs a recursive agent. From the
local source channel b it inputs the value to be forwarded, bound to x, and an
acknowledgement channel, bound to y. It then migrates to the second site k2 ,
generates a new acknowledgement channel ack that it transmits, together with
the value x, to the target channel c at k2 . It waits at the delivery site, k2 , for the
acknowledgement; when it arrives the agent returns to the source site k1 where in
turn it delivers its acknowledgement on y and awaits a new message on the source
channel.

The language aDpi inherits from aPi all the standard notational conventions, the
notions of free and bound variables and names, capture-avoiding substitutions and
α-equivalence. However, as we have seen in the introduction to this chapter, channel
names can appear in (location) types. This must be taken into account in the formal
definitions of the function for calculating free and bound names, fn(−), bn(−)
respectively, when applied to terms in aDpi. So for example in these definitions
applied to processes we have clauses of the form
 5.1 The language aDpi 131

Figure 5.4 Reduction semantics for aDpi

bn((new n : D) R) = bn(R) ∪ {n}

(5.3)
fn((new n : D) R) = (fn(R) ∪ n(D)) − {n}

where n(D) denotes the names that occur in the type expression D; this will be empty
unless D is a location type. A similar definition applies to system level terms, but
there is a subtlety associated with the, as of yet unexplained, scoping mechanism
(new e : D) M at the system level; this will be elaborated on below, in (5.4). We
will use the word system to denote a closed system term, that is a system term that
contains no free occurrences of variables. We will use the word process and agent
for closed process terms.
The reduction semantics is similar in style to that of aPi, and uses a structural
equivalence ≡ to factor out inessential details in the syntax. The reduction relation
is defined to be the least contextual relation between systems

M −→ N

that satisfies the rules in Figure 5.4. Note that the definition of contextual in
Definition 2.5 can be applied to systems, as they have both a parallel constructor
− | − and a new name constructor (new e : D)(−). The axioms (r-eq), (r-neq),
(r-str) and (r-unwind) are taken directly from the reduction semantics for aPi,
but now apply to located processes; the structural equivalence used in (r-str) is
inherited from aPi, although there is a complication involving bound names; this
will be explained presently.
The rule (r-comm) is also inherited from aPi, although note that the
communicating agents are obliged to be at the same location. Thus in aDpi
132 A distributed asynchronous pi-calculus

communication is local; agents who wish to communicate must be co-located,

and use a local channel for this communication.
The axiom (r-split) is novel. It allows the splitting of a concurrent agent located
at k to evolve into two concurrent located agents, each of course still located at k. It is
essentially a housekeeping move, as it allows systems to evolve into configurations
from which real reductions, such as communication, migration, or value testing,
can occur.
The new axiom (r-move)

k
goto l.P  −→ l
P 

accounts for migration. Note that migration is at the level of agent rather than
domain. In fact the latter would not make any sense in view of the flat structure of
domains.
Finally the creation rules allow us to export names declared by an individual agent
to the system level. The rule for exporting domain declarations, (r-l.create), is
straightforward; k
(newloc l : Dl ) (R) evolves to (new l : Dl ) (k
R). This may
seem an innocuous move, but the code R may now send an agent to the new
location, to install resources and run processes there. For example if R has the form
(P | goto l.Q) then we will have the reductions

k
(newloc l : Dl ) R −→−→−→ (new l : Dl ) (k
P  | l
Q)

where now the residual P running at the original k can broadcast the existence of
the new site l, and its resources; moreover the code Q has been installed at the new
site to service these resources. This is such a natural manner for generating new
locations that we introduce a specific notation for it.

Notation 5.4 We use (newloc l : Dl ) with Q in P to denote the process

(new l : Dl ) (P | goto l.Q)

The rules for creating local channels are similar. But note that in (r-c.create),
when the new channel c of type Dc , local to k, is exported to the system level, its
location has to be noted; the name c created locally at site k is referred to globally
as c@k. In other words at the system level we have simple names, k referring to
locations, and located names, c@k, referring to actual located channels or resources.
In future we use the meta-variable e to range over the corresponding compound
values, which may be simple values v, or located identifiers u@w where both u and
w are simple identifiers, that is either names or variables; so when variables are not
involved, these compound values are either simple names or located names.
There is a subtlety involved in the use of these located names. In the system
(new c@k:Dc ) (M ) only occurrences of c in M are bound; the location name k
 5.1 The language aDpi 133

Figure 5.5 Structural equivalence for aDpi

is simply used as a tag, to denote where this private resource c exists. So when
extending the notions of free and bound names to systems we must have the clauses
bn( (new c@k:Dc ) M ) = {c} ∪ bn(M )
(5.4)
fn( (new c@k:Dc ) M ) = ({k} ∪ fn(M ) ∪ n(Dc )) − {c}
The corresponding clauses for the other kind of name declarations are as discussed
above in (5.3).
These located names also have an effect on the definition of structural equivalence
between systems. As with aPi this is defined to be the largest contextual
equivalence that satisfies a set of axioms. These are given in Figure 5.5, and are
modelled directly on those for aPi in Figure 2.3. But note that now in (s-extr) we
have to be careful about the actual name being extruded; here bn(e) refers to c if e
is the located name c@k and otherwise is e itself. So for example, assuming there
is no occurrence of c in P,
(new c@l : Dc )(l
P  | k
Q) ≡ l
P  | (new c@l : Dc ) k
Q
Similarly in (s-flip) we have to make sure that the role of scoped names does not
become confused. For example
(new k : Dk ) (new c@k : Dc ) M  ≡ (new c@k : Dc ) (new k : Dk )M
because k is contained in c@k. The side-conditions placed on (s-flip) are a slight
generalisation of those used for typed aPi, discussed on page 61. Recall that types
may now contain names, and therefore we need also to ensure that the bound names
bn(e1 ), bn(e2 ) do not appear in the types D2 , D1 respectively.
Let us now look at some examples of the use of this reduction semantics; as usual
we will sometimes elide the actual types of bound names; indeed we continue to
do so throughout the chapter unless they are relevant to the discussion at hand. The
subject of the types required for bound names will be taken up in Section 5.2.
Example 5.5 Let us examine the possible reductions from the system
s
DprimeS | h
Client(11)
where the agents DprimeS and Client(11) are defined in Example 5.1.
134 A distributed asynchronous pi-calculus

These are two independent agents, each in evaluation contexts, and therefore are
subject to any of the applicable rules in Figure 5.4. For example the rule (r-unwind)
can be applied to s
DprimeS and we get the reduction

s
DprimeS | h
Client(11)
−→ (5.5)
s
inp ?(x, y@w) (DprimeS | goto w.y! isprime(x)
) | h
Client(11)

The server is now in a stable state, waiting on input at the port inp .
The client on the other hand needs first to extrude the new reply channel, using
(r-c.create):

h
Client(11) −→ (new r @h : Dr ) h
r?(x) print! x

| goto s.inp ! v, r @h


Putting this in context, that is applying the contextuality of reduction, we obtain

s
inp ?(x, y@w) . . . | h
Client(11)

−→
s
inp ?(x, y@w) . . . | (new r @h : Dr ) h
r?(x) print! x
| goto s.inp ! 11, r @h


The client is now ready to send the requesting agent to the server. But in order
to formally derive the reduction we need to use the structural equivalence to re-
arrange the system so that the relevant axioms can be applied. We have already seen
numerous instances of these re-arrangements in aPi, all using suitable applications
of the extrusion axiom (s-extr); for one example see Example 2.9.
First note that

s
. . . | (new r @h : Dr ) h
. . . ≡ (new r @h : Dr )(s
. . . | h
. . .)

because of the rule (s-extr); r does not occur free in h
. . .. Therefore applying
the rule (r-str) to the last reduction we obtain

s
inp ?(x, y@w) . . . | h
Client(11)

−→ (5.6)
(new r : Dr @h)( s
inp ?(x, y@w) . . . | h
r?(x) print! x
| goto s.inp ! 11, r @h
)

This we may take to be the second reduction step of the system.

At this stage we may use the rule (r-split) to obtain

h
goto s.inp ! 11, r @h

| r?(x) print! x
 −→ h
r?(x) print! x

| h
goto s.inp ! 11, r @h

 5.1 The language aDpi 135

thereby isolating the agent, currently at h, which is about to move. Applying this
reduction in context we obtain the third reduction step:
(new r @h : Dr )( s
inp ?(x, y@w) . . . | h
r?(x) print! x
| goto s.inp ! 11, r @h
 )
−→ (new r @h : Dr )( s
inp ?(x, y@w) . . .|
h
r?(x) print! x
 | h
goto s.inp ! 11, r @h
 ) (5.7)
Here the migration of the agent may be derived using (r-move):
h
goto s.inp ! 11, r @h
 −→ s
inp ! 11, r @h

and applying this in context, together with an application of (r-str), gives
(new r : Dr @h)(s
inp ?(x, y@w) . . . | h
r?(x) print! x
 | h
goto s.inp ! 11, r @h
)
−→ (5.8)
(new r : Dr @h)(s
inp ?(x, y@w) . . . | s
inp ! 11, r @h
 | h
r?(x) print! x
)
We now have at the server site s
• an agent who wishes to transmit a message along the local channel inp
• and an agent who is willing to service this message.
The axiom (r-comm) may be used to obtain
s
inp ?(x, y@w) . . . | s
inp ! 11, r @h
 −→ s
DprimeS | goto h.r! isprime(11)

For variety let us use (r-split) on the resulting system, to obtain
s
inp ?(x, y@w) . . . | s
inp ! 11, r @h
 −→−→ s
DprimeS
| s
goto h.r! isprime(11)


Applying these two reductions in context we obtain the reductions

(new r @h : Dr )(s
inp ?(x, y@w) . . . | s
inp ! 11, r @h
 | h
r?(x) print! x
)
−→−→ (5.9)
(new r @h : Dr )(s
DprimeS | s
goto h.r! isprime(11)
 | h
r?(x) print! x
)
Now there is the return agent, currently at s, which can migrate back to h. As
explained in Example 2.10, let us elide the evaluation of isprime(11), assuming it
is some computation done at the server, and then (r-move) can be used to give
s
goto h.r! isprime(11)
  s
goto h.r! true
 −→ h
r! true

where  represents the elided evaluation of isprime(11). In context this gives
(new r @h : Dr )(s
DprimeS | s
goto h.r! isprime(11)
 | h
r?(x) print! x
)
−→ (5.10)
(new r @h : Dr )(s
DprimeS | h
r! true
 | h
r?(x) print! x
)
136 A distributed asynchronous pi-calculus

Now there is a local communication possible at h, along the reply channel r. From
(r-comm) we obtain
h
r! true
 | h
r?(x) print! x
 −→ h
print! true

that in context gives the reduction
(new r @h : Dr )(s
DprimeS | h
r! true
 | h
r?(x) print! x
)
−→
(new r @h : Dr )(s
DprimeS | h
print! true
)
However the channel name r does not appear free in the code DprimeS, or in the
code at h and so using the derived structural equation
(new e : D) N ≡ N if bn(e) ∈ fn(N )
similar to that discussed in Example 2.9, and an application of (r-str) we obtain
the final reduction
(new r @h : Dr )(s
DprimeS | h
r! isprime(11)
 | h
r?(x) print! x
)
−→ (5.11)
s
DprimeS | h
print! true


So in eight steps, ignoring the computation of isprime(11), we have seen the

reduction of the system
s
DprimeS | h
Client(11)
with a server and a client, to one of the form
s
DprimeS | h
print! true

where the client has been serviced and the server is ready to accommodate further
requests.
The first three reductions (5.5), (5.6), (5.7) are house-keeping in nature, preparing
the system for the significant reductions, namely migration via the axiom (r-move)
and local communication via (r-comm). The fourth reduction (5.8) sees the client
send an agent to the server, while in (5.9) there is a communication at the server
site; the server is informed of the client’s request. After the evaluation of the call to
isprime(−), the answer is given to an agent at the server site that, in the next move
(5.10) migrates to the client site, and in (5.11) there is a local communication this
time at the client site informing it of the result.

Example 5.6 [A Located Memory ] Here we give a located version of the memory
cell from Example 2.11. The cell takes the form
m
LMem
 5.1 The language aDpi 137

where m is the location of the cell and LMem is the code running there. This is
much the same as the code Mem from Example 2.11 except that now the locations
of the methods must be catered for:
LMem ⇐ (newc s : S) (s! 0

| rec p. get?(y@w) s?(z) (w.y! z

| s! z
| p)
| rec g. put?(x, y@w) s?(z) (w.y! | s! x
| g)
Here the access methods require located return channels, bound by the pattern y@w,
at which to deliver the result of an access. Note that we are using the abbreviation
introduced in Notation 5.2.
A client is in turn expected to be located, of the form
c
Client
where Client, when calling the cell methods, must use c as the location of the
return channels. It must also be aware of the location hosting the cell. The client
corresponding to that in Example 2.11 is given by
Client ⇐ (newc a : Da ) (m.put! 4, a@c

| a? (newc r : Dr ) ( m.get! r @c
| r?(x) print! x
)
The reduction semantics can be applied to the system
m
LMem | c
Client
and many different sequences of reductions are possible. But the variations are
minor. All will involve four applications of the axiom (r-comm), two at the
memory site m and two at client site c. They will also require four applications
of (r-move), two in each direction, together with some house-keeping moves
involving (r-c.create), (r-split) and (r-unwind). There is some variation in
the sequence of application of these rules but all sequences will eventually end in
a system structurally equivalent to
m
LMem | c
print! 4


Although the mobility construct of aDpi, goto k.P, is elementary it can be used
to describe more complex frameworks, such as code servers that on request will
initialise code at different locations. A typical generic example is given by:
server
init?(x, y) goto y.code(x)
Here code(x) represents some general useful code, with some initialisation
paramater x. The code server, located at server receives requests at init, which
expects to receive some initialisation data say n, to be bound to x, and a location k,
138 A distributed asynchronous pi-calculus

to be bound to y. It spawns an agent that migrates to k and runs the intialised code
code(n) there.
Of course to be useful this server must be able to respond to repeated requests.
This is easily achieved, by transforming the body into a recursive agent. We pursue
this idea in the following example.
Example 5.7 [A Located Memory Server ] Let us now see how to describe a
distributed version of the memory service described in Example 3.15. We will
in fact see two versions.
The server takes the form
s
LmemS (5.12)
where LmemS is the code assuring the service. The server location s contains a
request channel req where requests are received. A client sends a reply address, a
located channel, the server generates a new located memory cell, using the code
of the previous example LMem, and delivers the new location name at the reply
address:

LmemS ⇐ rec z. req?(y@w) (newloc m : M) with LMem in (z | w.y! m

)

A system containing the server and two clients takes the form

s
LmemS | c1
Client1  | c2
Client2  (5.13)

where now the client-side code is defined by

Clienti ⇐ (newc r : Dr ) (s.req! r @ci

| r?(x) Ci (x))

A client generates a new reply channel, sends a request to the server, for which it
needs to know the address of the server, the location s and the appropriate method
there req, and awaits for the server to deliver the location of the new memory cell.
The reduction semantics, including a judicious use of the structural equivalence,
can be used to deduce a derivation from the system (5.13) to the system

s
LmemS | (new m1 : M)(m1
LMem | c1
C1 (m1 )) (5.14)

| (new m2 : M)(m2
LMem | c2
C2 (m2 ))

There are a number of points worth making about this system. First the type system
needs to ensure that friends of, say the first client, who have gained capabilities
on the instances of put and get at m1 cannot use these capabilities at m2 . Also
the form of the resulting system (5.14) indicates that Clienti has control over
knowledge of its respective memory mi . By extending the capability based type
system of Section 3.4 to aDpi we can ensure that these clients can selectively
distribute restricted capabilities on their own memory cells.
 5.2 Access control types for aDpi 139

Also the methods put and get now exist at two separate locations, m1 and m2 .
The type system will allow such use of method, or resource, names. Here the server
ensures that they are declared with the same type but a priori our typechecking
system will not impose any type consistency between the various instantiations of
a resource name at different locations. This question will be addressed in Section 5.5.
The server we have defined, in (5.12) above, has the responsibility to generate
the location of the memory cell. An alternative strategy would be for the clients
themselves to generate the site, send the name to the server, who then installs the
appropriate servicing code at the proffered site. Here the server code, running at
the server site s, takes the form

LmemSVbis ⇐ rec z. req?(x, y@w) (z | goto x.LMem | w.y!)

whereas that of a client is given by

Clientbisi ⇐ (newc a : Da )
(newloc m : M) with s.req! (mi , a@ci )
in a? Ci (m)

A client, such as

c1
Clientbis1 

generates an acknowledgement channel a and a new location m with the installed

code
s.req! (m1 , a@c1 )

This of course immediately leaves the newly created site to deliver a request to the
server. Meanwhile at the client’s site c1 an acknowledgement is awaited from the
server that the servicing code has been installed at m1 .
Once more the reduction semantics can be used to reduce the system

s
LmemSVbis | c1
Clientbis1  | c2
Clientbis2 

to one similar to (5.14) above; only the server is different.

5.2 Access control types for ADPI

In this section we explain the (capability) types for aDpi, and the typechecking
system, a direct generalisation of the treatment of aPi in Section 3.4. This is best
viewed as a mechanism for controlling the capabilities or permissions on declared
names. Since these names now include domain or location names, and the names
of resources local to these domains, controlling capabilities on them essentially
amounts to controlling the access by agents to domain resources.
140 A distributed asynchronous pi-calculus

5.2.1 The types

The collection of types is described informally in Figure 5.6 and is an extension
of those in Figure 3.6. Channel types remain the same, but now are considered to
be the types appropriate to local channels. A value sent at a type such as rw T

is considered to be a channel local to the domain in which the communication

happens; recall that rw T
is shorthand for the type rw T, T
. Non-local channels
must be transmitted at global channel types; a value at such a type is a located
name r @h, where r is a channel located at the domain h. In Example 5.1 the service
receives a value of this form, an address to which the result is to be returned. These
global channel types take the form
C@loc
with C representing the capabilities of the channel, and the tag loc the fact that the
(unknown) location of the channel arrives with it.
We have already discussed, in the introduction to this chapter, the types of domain
names, location types. These take the form
loc[a1 : C1 , . . . an : Cn ], n ≥ 0
where all resource names ai are distinct. We do not distinguish between location
types that differ only in the ordering of the resource names; we also use loc as an
abbreviation for the empty record type loc[].
The set of transmission types determines the values that can be legally sent and
received along channels. As with aPi, these are tuples of value types. These in turn
consist of the base types, local and global channel types, and location types. Note
that in Figure 5.6 we have also introduced the meta-variable D for types that can
be associated with name declarations in systems and agents. Unlike in the previous
chapter, here, for the sake of clarity, we will tend to use the more specific meta-
types, C for the declaration of a local channel and K for a location, when names are
declared; but in the next chapter we will make heavy use of the more generic D.

Figure 5.6 Types for aDpi – informal

 5.2 Access control types for aDpi 141

Figure 5.7 Subtyping for aDpi

The subtyping relation between types is a direct generalisation of that used for
aPi. The defining rules are given in Figure 5.7 and are a natural extension of those
in Figure 3.7 for aPi types. As already mentioned in the introduction the main new
rule pertains to location types. Whenever k ≤ n, and Ci <: Ci for each i between
0 and k, we can conclude
loc[a1 : C1 , . . . , an : Cn ] <: loc[a1 : C1 , . . . , ak : Ck ]
Note that this implies L <: loc for every location type L. The relation is extended
to global channel types homomorphically with the rule (sub-hom).
Definition 5.8 (capability types for ADPI) We define the capability types for aDpi
to be the set of all T such that
T <: T
can be derived using the subtyping rules, given in Figure 5.7. We reuse Types for
this set of valid types, and will also use the notation  T : ty to denote the fact that
T is a valid type. 

Proposition 5.9 The pre-order Types, <:

is partially complete.
Proof: (outline) To show that <: is actually a pre-order on Types the same technique
as in Lemma 3.18 can be employed.
The definition of the partial meet and partial join operation given in
Proposition 3.20 can be extended in a natural manner for the new types. On global
channel types we simply use induction while on location types the (partial) meet
operation is defined point-wise. If K, L are the types
loc[a1 : C1 , . . . an : Cn ] and loc[b1 : C1 , . . . bn : Cn ]
respectively, then K  L is defined only when ai = bj implies Ci ↓ Cj . In this case
it is defined to be
loc[c1 : D1 , . . . , cm : Dk ]
where c1 , . . . , ck , . . . , cm consists of all the ai and bj , and Dk is given by:
142 A distributed asynchronous pi-calculus

• If ck = ai = bj then Dk is defined to be Ci  Cj ; because resource names are unique in

location types there will be at most one such pair i, j.
• If ck = ai and ai does not appear in the L then Dk is defined to be Ci .
• Symmetrically if ck = bj and bj does not appear in K then Dk is defined to be Cj .

The join operation, total on location types, is defined in a slightly different manner;
K L is given by
loc[c1 : D1 , . . . , cm : Dk ]
where this time c1 , . . . , ck , . . . , cm is the set of names that appear in both a1 . . . an
and b1 . . . bn and for which the corresponding type Dk exists; if ck = ai = bj then
Dk is taken to be Ci Cj .
So for example if K, L are

loc[a : w int
, b : w bool
] loc[a : r int
, c : r bool
]

respectively, then K  L, K L are

loc[a : rw int
, b : w bool
, c : r bool
] and loc[]

respectively. If L had the additional resource b : r int

then K  L would no
longer exist since r bool
and w int
, the entries for b in K, L respectively, are
not consistent. On the other hand K L would still be well-defined, as is a total
operation on location types; it would still be equal to loc[]. If the type of a in K
were changed to rw int
then K L would be the non-trivial type loc[a : r int
].
We leave the reader to check that the proof given in Proposition 3.20 can be
extended, to these new definitions.

5.2.2 Type environments

Typechecking in aDpi is organised in a manner similar to that in aPi, but now with
additional judgements of the form

  M

where M is a system term and  a type environment. Here type environments are
more complicated, which is not surprising in view of the range of roles declared
names may play. The main added complexity stems from the fact that some
names only have local significance, those used for resources, while others, those
used for locations, have global significance. Consequently we need to introduce
some additional notation, which at first sight may seem unnecessarily tedious.
However we will quickly develop some conventions that will tame the added
complexity.
 5.2 Access control types for aDpi 143

Again type environments are lists of associations between identifiers and types,
and the following forms are allowed:
• u : loc, indicating that u is the name of a domain
• u@w : C, indicating that the identifier u, used at the domain w, represents a resource at
type C there; these are local channel type associations
• x@w : proc, indicating that the variable x is used in the definition of a recursive process,
running at location w
• x : base, indicating that the variable x is to be bound to a base value of type base.

It is important to note that in u@w : C both u and w may be identifiers; both may
be either names or variables. These will be essential to type systems such as

k
a?(x@y) goto y.x?(z) P 

Here we will eventually end up typing the body x?(z) P relative to an environment
with the associations x@y : C, and y : loc.
As with aPi, it is convenient to have an extra meta-variable for the class of types
that can appear in these new environments; we re-use that employed in Chapter 3:

E ::= loc | C | base | proc (5.15)

Thus environments will be restricted lists of the

e1 : E1 , e2 : E2 , . . . , en : En , n ≥ 0

These restrictions are enforced by giving an inductive definition of valid

environments, using an extension of the rules in Figure 3.8 for aPi, and, as in
that case, the rules for the assignment of types to values are given simultaneously.
But here there is a slight change. Certain resource names may exist in one domain
and not in another, and therefore identifiers can only be assigned types, relative to
a given domain. The judgements therefore take the form

 w V :T (5.16)

and are designed so that they can only be inferred when w is known in  to be a
domain name. But, as we shall see, in many cases the actual location w may be
omitted from these judgements.
First let us consider the rules for valid environment formation. Recall that for
typed aPi, because of our view of types as capabilities, we allowed multiple entries
for a given identifier, provided all the entries were consistent. Here we carry over
this idea, but now consistency will in general be relative to a specific location.

Definition 5.10 (local consistency) Let  ↓w u : E denote the fact that for every
type E ,  w u : E implies E ↓ E.
144 A distributed asynchronous pi-calculus

Figure 5.8 Type environments in aDpi

Figure 5.9 Typing values in aDpi

As we shall see for many types, in particular location types, this predicate is
actually independent of the particular location w, and therefore it will often be
omitted. 
The rules for constructing new environments are given in Figure 5.8, although the
base case, (e-empty) from Figure 3.3 is omitted. It will be technically convenient
to allow multiple entries of location name declarations, and variables of base type.
This is allowed by the rules (e-loc) and (e-base), where the side-conditions use the
notation just introduced. Also note that the rule for introducing recursion variables,
(e-proc), ensures that these are declared at a specific location. The rule for adding
local channel names is very natural. To add the entry u@w : C we have to ensure w
is actually a location, and that the type C is consistent with all existing entries for
u at the proposed location w, that is  ↓w u : C.
The rules for type assignment to values are given in Figure 5.9, and many
are adapted directly from Figure 3.9, the corresponding rules for aPi, to take
 5.2 Access control types for aDpi 145

into account the fact that judgements are now local to a particular domain. The
environment look-up rule from there, (ty-sub), now has four different versions
depending on the type of the identifier in question. The first two, (ty-c.sub)
for channels and (ty-proc.sub) for recursive definitions, are local. The slightly
artificial rule (ty-loc.sub) for locations is required in order to be able to apply
the global rule (ty-g.sub); because of our constraints on environment formation
this can only be used when E is either a base type, or the degenerate loc. The new
rule (ty-loc) is used to assign a location type K = loc[a1 : C1 , . . . an : Cn ] to
an identifier, while (ty-located.channel) is the obvious rule to assign a global
channel type to a located identifier. Notice that in both these new rules w, the location
at which this typing is inferred, plays a limited role. This is true of many types in
the judgements (5.16) above, and we will call such types global; specifically value
types of the form base, K and C@loc are said to be global, while a transmission
type T is global if all of its components are global. We leave the reader to check
the following simple observation:
Lemma 5.11 If T is a global type then  w V : T implies  w  V : T for every w
such that   w : loc.

Consequently we will often omit these locations, for example writing   w : K

for a location type K, if for any u,  u K.
As we have seen in Chapter 3 for aPi, typechecking requires the dynamic
construction of environments, as the analysis of a term proceeds. For example
the rule (ty-in) in Figure 3.10, which is aimed at typing the aPi term u?(X ) R
relative to the environment , requires the analysis of R in the extended environment
, X :T
, for some type T. This new environment is construed to be  to which
has been added the association list X :T
obtained from the pattern X and the type
T. In aDpi these patterns are more complicated as they involve compound values,
and moreover typechecking will be relative to a specific location, as resources
are location specific. We need a generalisation of Definition 3.2, for constructing
environments from values and types.

Figure 5.10 Typing systems

146 A distributed asynchronous pi-calculus

Definition 5.12 (constructing environments) We define an association list V :T

@w
from a value V , an identifier w and a transmission type T, by induction on the
structure of the value.
• V is a base value bv. Then T must be the base type of bv and in this case the result is the
empty list.
• V is a variable x and T is a base value base. Then V :T
@w is the singleton list x : base.
• V is an identifier u and T is a local channel type C. Then V :T
@w is the singleton list
u@w : C.
• V is an identifier u and T is a location type loc[a1 : C1 , . . . , ak : Ck ]. Here V :T
@w is
the list u : loc, a1 @u : C1 , . . . , ak @u : Ck . Note that in this case w plays no role in the
construction of the list.
• V is the located identifier u@v. Here T must have the form C@loc and again, the resulting
list V :T
@w will be independent of w. It is constructed in the natural manner, giving
v : loc, u@v : C.
• V is the tuple (V1 , . . . , Vn ). In this case we need T to be of the form (A1 , . . . , An ), in which
case the resulting list V :T
@w is constructed by induction: V1 :A1
@w, . . . , Vn :An
@w.


It is worthwhile comparing this definition with the corresponding one for aPi,
Definition 3.2. Here we need the extra parameter, a location w, which is actually
only used in the case of a (local) channel type C. In addition we need two new
cases, for location types, and for located identifiers. But note that for global types,
as we have defined above, w plays no role. For such types we will often abbreviate
V :T
@w to simply V :T
. Indeed this global notation may be further extended by
letting u@w:C
be the singleton list, u@w : C. In this way we will have a way of
constructing a type association list e:D
for every name creation (new e : D)(−)
allowed in well-typed aDpi systems; this notation will be used extensively in the
following chapter.
But again note that these lists, both located and unlocated, are only defined if the
structure of the value V matches that of the type T, and in many cases the result is
not a valid environment; for example in the case for tuples the different components
may add conflicting information about an identifier to the list. However, there is
a simple criterion for being able to extend well-defined type environments with
these lists, at least in the case of simple values; this is a generalisation of the rule
(e-chan) from Figure 5.8.
Lemma 5.13 (extension lemma) Suppose   env. Then  ↓w u : D implies
, u:D
@w  env.
Proof: If D is a local channel type this follows from (e-chan); so let us assume
it is the location type loc[c1 : C1 , . . . cn : Cn ]; we have to show , u : loc, c1 @u :
C1 , . . . , cn @w : Cn  env.
 5.2 Access control types for aDpi 147

First  ↓w u : D implies  ↓w u : loc and therefore an application of (e-loc)

gives , u : loc  env. Now, in order to apply (e-chan), suppose , u : loc u c1 : C.
This must mean that   u : loc and  u c1 : C, and therefore   u : loc[c1 : C].
From  ↓w u : D it follows that loc[c1 : C] ↓ D, which can only be the case if
C ↓ C1 . Therefore an application of (e-chan) gives , u : loc, c1 @u : C1  env.
This argument can be repeated for each entry ci @u : Ci because all cj are distinct.

5.2.3 Typechecking
At last we are in a position to give the typechecking rules for aDpi systems. As we
have already noted judgements are of the form

  M

where  is an association list and M a system; the inference rules are given in
Figure 5.10. These are designed so that such a judgement can only be inferred
when  is a valid type environment and, as usual, they can only be applied to
systems M whose bound names do not appear in . The rule (ty-zero) says that
the empty system 0 is well-typed relative to any valid type environment . To
ensure the composite system M | N is well-typed, the rule (ty-con) dictates that
it is sufficient to infer that the individual components M and N are well-typed.
There are two different kinds of entities that can be declared globally for a system
and for the sake of clarity each has its own inference rule. First let us consider the
declaration of local resources, which is straightforward. According to (ty-cnew)
the system (new c@k : C) M is well-typed relative to ,

  (new c@k : C) M (5.17)

provided M is well-typed relative to the extended association list , c@k : C. In

writing (5.17) we are assuming that the bound name c does not appear in , but
nevertheless we are not necessarily guaranteed that this extended association list
is in fact a valid type environment; the location of the newly declared channel, k,
needs to be known to . Of course this is not stated explicitly as a requirement but
at some point in the derivation of

, c@k : C  M

it will be necessary to check that , c@k : C is a valid environment, and to do so

it will need to be the case that   k : loc.
The declaration of new locations, in rule (ty-lnew), is similar; the body M
is typechecked relative to the association list , k:K
. Once more implicitly this
will only be possible if the augmented list turns out to be a well-defined type
148 A distributed asynchronous pi-calculus

environment. It is also worth noting that, using the notation introduced on page 146
after Definition 5.12, these two rules can be subsumed by the more generic:
(ty-new)
, e:D
 M
  (new e : D) M
However for the sake of clarity, we have preferred to spell out the individual cases.
Finally, to typecheck the located agent k
P  relative to  we use the rule
(ty-agent); this ensures that the agent it well-typed to run at k. Agents need to be
checked relative to locations because of the use of local channels. For example the
agent
c?(x) R
will only be well-typed to run at a location k if there is a local channel named c
declared at k. Thus for agents we require judgements of the form
 w P : proc
indicating that P is well-typed to run at location w. An instance of this is used in
(ty-agent) to check that the located agent k
P  is well-typed.
So now let us turn to this typechecking of agent terms, relative to a location
w. The inference rules are given in Figure 5.11 and, although relativised to the
location w, have much in common with those for typechecking aPi, in Figure 3.10
and Figure 3.5. The rules (ty-stop) and (ty-par) are inherited directly while the
rules for input and output are minor variations. For example to infer
 w u?(X ) R : proc
we must ensure that u is a channel declared locally at w, with an appropriate
capability,
 w u : r T

and that the residual R can be typed, relative to w, in an extended environment.

This is obtained by extending  with the type associations X :T
@w. Again our
assumption about bound identifiers ensures that the variables in X are new to ; so
if  is a valid environment in which w is known to be a location, the extension will
also be, provided that the structure of the pattern X matches that of the type T.
Similarly to ensure u! V
is well-typed to run at w, relative to , we must ensure
• u is declared at the location w and can be assigned some write capability appropriate to
the transmission of V ,
 w u : w T

• and at w the value to be transmitted, V , can be assigned the transmission type T,

 w V :T
 5.2 Access control types for aDpi 149

Figure 5.11 Typing agents

Typing the migration construct, with (ty-go), is straightforward. We can infer

 w goto u.R : proc
provided u is known to  as a domain,
  u : loc
and the agent R is well-typed to run at the target domain u,
 u R : proc

There are two rules for typing local declarations, (ty-cp.new), (ty-lp.new). We
have already discussed at length the corresponding rules at the system level, and
these are very similar. For example to typecheck
(newc c : C) R
relative to  at the location w, we need to typecheck the process term R relative to
the extended environment , c@w : C. Because we are typechecking the process
to run at w the locally declared channel c is added to the environment with the
compound name c@w.
150 A distributed asynchronous pi-calculus

Typechecking the match construct

if v1 = v2 then R1 else R2
is handled by the obvious localised versions of the corresponding rules for typed
aPi. Finally note that the typechecking of a recursive process rec x. B, via (ty-rec),
is always carried out relative to a specific domain w; in effect each recursive call
to its body must be at the same location.

5.2.4 Examples
Throughout this section, and indeed for the remainder of the chapter we will
abbreviate the agent judgements  w P : proc to simply  w P.
As a first example let us consider how pattern matching, and the environment
construction mechanism given in Definition 5.12, plays a central role in
distinguishing between local and global channels.
Example 5.14 [Pattern Matching ] First suppose that 1 is a (valid) type
environment that contains the type association in@s : rw rw int

. Then one can

check that
1  s
in?(x) x! 7

This follows using (ty-agent) in Figure 5.10 from
1 s in?(x) x! 7

which in turn requires an application of (ty-in) in Figure 5.11 to

1 , x:rw int

@s s x! 7
(5.18)
since, by (ty-c.sub) of Figure 5.9, 1 s in : r rw int

. The important point to note

about this judgement, (5.18), is that the environment unravels, via Definition 5.12,
to 1 , x@s : rw int
. In other words the incoming value on in, bound to x, is taken
to be a channel name local to the site s; because of this the judgement (5.18) is
easily established, via (ty-out).
For this reason a system such as
s
in?(x) goto k.x! 7

cannot be typed relative to 1 , even if k is known in 1 as a location. For this would
require, via (ty-go), the judgement
1 , x@s : rw int
k x! 7

This in turn could only be inferred via (ty-out), which would require
1 , x@s : rw int
k x : w int

 5.2 Access control types for aDpi 151

This of course is impossible, as x has just been established as a channel name local
to the original site at which it was received, s; as a bound variable in the system
being typed, x cannot occur in 1 .
Channels that are not local to the domain s can only be received at s as part of a
compound value. To see how these are typed let 2 be an environment such that
2 s in : rw rw int
@loc

Then we can infer the judgement

2  s
in?(x@y) goto y.x! 7
 (5.19)
Here a compound value is received at in, consisting of a location, bound to y, and
a channel, bound to x, which is presumed to exist at the location y. Establishing
(5.19) requires
2 , x@y:rw int
@loc
@s s goto y.x! 7
(5.20)
Here the environment unravels, via Definition 5.12, to 2 , y : loc, x@y : rw int

and consequently (5.20) is easily derived using (ty-go) and (ty-out), as x has
been recorded as a channel located at y.
However channels can sometimes be assumed to exist by virtue of their
occurrence in a location type. To illustrate this consider a third environment 3
such that
3 s in : rw L
where L = loc[r : w int
]
Then
3  s
in?(y) goto y.r! 7

can be established. The crucial step is to derive
3 , y:L
@s s goto y.r! 7

However this is straightforward as the augmented environment unravels to 3 , y :

loc, r @y : w int
. Because of the type of the channel at which y is received, we
know that it is a location at which there is a channel named r at type w int
.

In the next example we examine the declaration of channels and see how the
typing system enforces the local nature of their use.
Example 5.15 (Local Channel Declarations) Consider the following system:
M1 ⇐ l
(new c : rw int
) goto s.(c! 1
| c?(x) R)
An agent declares a channel c at the location l, migrates to s, and then tries to use
c at the new location. Intuitively there is something amiss here; c is declared to be
a resource available at l, but an attempt is made to use it at a different location.
152 A distributed asynchronous pi-calculus

Indeed one can check that for no  can the judgement

  M1
be established. This would require an application of (ty-agent), preceded by an
application of (ty-cp.new) to
, c@l : rw int
l goto s.(c! 1
| c?(x) R)
that in turn would require establishing, among other things
, c@l : rw int
s c! 1

But this is clearly impossible. We know c is fresh to , and so (ty-out) can never
be used here, since c only exists at the location l, and not s.
As a variation consider
M2 ⇐ l
(new c : rw int
) goto s.in! c

and the type environment 1 used in the previous example; it has the type association
in@s : rw rw int

. Then one can check that M2 cannot be checked relative to 1 .

Again the intuition should be clear. The channel in at location s can only transmit
local resources, while an attempt is made to send the resource c, declared at l, on
it. Formally the typing judgement 1  M2 cannot be established because it would
require the judgement
1 , c@l : rw int
s c : rw int

that is clearly not possible.

However if 2 has the entry in@s : rw rw int
@loc
, as in the previous example,
then the reader should be able to establish   M3 where
M3 ⇐ l
(new c : rw int
) goto s.in! c@l

In other words non-local channels can be transmitted at s, provided their location
is transmitted at the same time.

Now let us consider the typing of the distributed compute server in Example 5.1.
Example 5.16 (Typing the Distributed Compute Server) Let us first consider the
service code DprimeS running at the site s. Here we also assume the rule
(ty-op)
  u : int
(5.21)
 w isprime(u) : bool
a distributed version of the rule (3.12) in Chapter 3, page 65; essentially this says
that the isprime is available globally, as an operator from integers to booleans. Let
 be any valid environment that contains the entry
inp @s : rw (int, w bool
@loc)

 5.2 Access control types for aDpi 153

So inp is known to be a channel at the site s that can be used for both reading
and writing of pairs, the first of which must be an integer. A value at the type
w bool
@loc is a global channel along which may be sent a boolean; thus the value
will be a located name, of the form a@l, where a is located at l. To see how we can
derive the judgement
  s
DprimeS
let us work backwards through a derivation. This will follow from
 s DprimeS (5.22)
using (ty-agent). To get to (5.22) an application of (ty-rec) to
, z @s : proc s inp ?(x, y@w) (z | goto w.y! isprime(x)
)
is required. Here we need an instance of (ty-in). From our assumption we know
that
 s inp : r int, w bool
@loc

This judgement is an instance of (ty-c.sub) from Figure 5.9 and uses the
subtyping relation. Also Definition 5.12 can be applied to calculate the environment
(x, y@w):(int, w bool
@loc)
@s, giving
x : int, w : loc, y@w : w bool

and therefore we need to establish

, z @s : proc, x : int, w : loc, y@w : w bool
s z | goto w.y! isprime(x)
(5.23)
In this agent term the dominant operator is | and therefore to derive (5.23) an
application of (ty-par) is required. One of the premises is a simple lookup of the
located recursion variable z @s, using (ty-proc.sub), and therefore we are left with
the premise
, z @s : proc, x : int, w : loc, y@w : w bool
s goto w.y! isprime(x)

This will follow, by (ty-go), from

, z @s : proc, x : int, w : loc, y@w : w bool
w y! isprime(x)
(5.24)
It is easy to derive
, z @s : proc, x : int, w : loc, y@w : w bool
w y : w bool

that is one of the premises for an application of (ty-out) with (5.24) as a conclusion.
The other premise
, z @w : proc, x : int, w : loc, y@w : w bool
w isprime(x) : bool
154 A distributed asynchronous pi-calculus

follows, assuming an application of the rule (5.21) to the expression isprime(x),

since we have
, z @w : proc, x : int, w : loc, y@w : w bool
 x : int

Let us now consider a typing for a client of this service:

h
(newc r : Dr ) (r?(x) print! x
| goto s.inp ! 11, r @h
)
A priori the client should also be typeable with the  used above, provided this also
contains an appropriate type for the print channel:
 h print : w bool

But we have to decide on the type Dr for the generated reply channel. We have seen
that the server requires a write capability on any reply channel it receives while the
client reads from it. So we let
Dr = rw bool

Then we can derive the judgement

 h (newc r : Dr ) (r?(x) print! x
| goto s.inp ! 11, r @h
)
Note that this will only be typeable at the site h because the newly generated reply
channel is exported as the global channel r @h.
The last step in this derivation is an application of (ty-cp.new) to
, r @h : Dr h r?(x) print! x
| goto s.inp ! 11, r @h
(5.25)
Note that here the newly generated channel r has been added to the environment as
existing at the site h. The derivation of (5.25) requires an application of (ty-par)
to the two judgements
, r @h : Dr h goto s.inp ! 11, r @h
(5.26)
and
, r @h : Dr h r?(x) print! x

We only consider the first of these, (5.26). As above we can deduce , via (ty-c.sub),

 s inp : w (int, w bool

@loc)
(5.27)
and
, r @h : Dr s 11, r @h
: int, w bool
@loc
(5.28)
Note that this latter inference also involves the use of subtyping, and requires  
h : loc. Moreover these are global types, and so the actual location of the inference,
 5.2 Access control types for aDpi 155

s, is unimportant. Now (5.27) and (5.28) can serve as premises to (ty-out) to

deduce the judgement
, r @h : Dr s inp ! 11, r @h

The rule (ty-go) may then be applied, to obtain the required (5.26).

Example 5.17 (Typing the Memory Cell) Here we examine what is required to type
the code for a memory cell
LMem ⇐ (new s : S)(s! 0

| rec g. get?(y@w) s?(z) (w.y! z

| s! z
| g)
| rec p. put?(x, y@w) s?(z) (w.y! | s! x
| p)
as defined in Example 5.6. The internal resource s is both written to and read from,
and so the declaration type S should be the type rw int
.
The method get expects to receive write permission on some located integer
channel. That is, it expects values of type
Tg = w int
@loc
Similarly the method put expects an integer together with write permission on a
located acknowledgement channel. So let
Tp = (int, w@loc)
Then to type the code LMem at a site m we need
 m get : r Tg

 m put : r Tp

Note that the functionality of the code LMem is independent of its location, provided
that location hosts a declaration of put and get at these types.
In Example 5.6 we saw the behaviour of a typical client of a memory, residing
at the site c:
Client ⇐ (newc a : Da ) (m.put! 4, a@c

| a? (new r : Dr )(m.get! r @c
| r?(x) print! x
)
This generates two local channels, an acknowledgement channel a whose
declaration type should be
Da = rw
and an integer reply channel r whose declaration type is required to be
Dr = rw int

156 A distributed asynchronous pi-calculus

In each case the write permission is exported, to the memory, and the read permission
is retained by the client. So, to type the client code we need
 c get : w Tg

 c put : w Tp

 c print : w int

Then with such an environment  we can derive

 c Client
where c is the site of the client.
To sum up let us collect the requirements on a type environment necessary to
type the overall system
m
LMem | c
Client
A review of the discussion will confirm that the system can be typed in any
environment that has the entries
get@m : rw Tg
, put@m : rw Tp
, print @c : w int

provided that the locally declared names, a and r are declared at the types Da and
Dr respectively. Note that the client’s code requires not only the knowledge of the
server’s location, m, but also its own location c.

Example 5.18 [Typing the Located Memory Servers ] Let us consider the typing of
the memory services discussed in Example 5.7. First let us consider the minimal
requirements on req in order to be able to derive
req  s
LmemS | c1
Client1  | c2
Client2  (5.29)
where the code for LmemS and the clients may be found in Example 5.7. The
server, in response to a request, generates a new location m at type M and installs
the code LMem there. We have just discussed the typing of this code, and from this
discussion it should be apparent that the declaration type M should be
loc[put : rw Tp
, get : rw Tg
] (5.30)
where Tp and Tg are (int, w@loc) and w int
@loc respectively. Note that although
the server only uses the read capability on put and get, clients require the write
capability, and therefore both must be in the declaration type of m.
The clients generate return channels at type Dr on which the name of the newly
generated channel is to be sent. Therefore we need to set this declaration type to be
rw M
; again the clients only use the read capability but the sever uses the write.
The request channel req is a free name in the overall system, being read by
the server, and written to by the clients; it must therefore be assigned a type by
 5.2 Access control types for aDpi 157

req . The values being transmitted on req are the return channels generated by the
clients. So one possibility would be for it to have the type rw Dr @loc
; note that the
transmission type is a global channel, as the return channel must be accompanied
by its location. But this is unnecessarily liberal, as the return channels will only
be written to by the server. So a sufficient type for req to have in req is the more
restricted rw w M
@loc
.
Summing up, we leave the reader to check that (5.29) can be derived whenever
• req  req : rw w M
@loc

• the client code r?(x)Ci (x) is properly typed, that is req , x:M
ci Ci (x).

But there is a subtlety involved in establishing the judgement (5.29) above. The
names put and get are used both by the server, in the declaration type M of the
new locations, and the clients, in the declaration type Dr of the return channels.
These are completely independent systems and a priori could independently assign
conflicting types to these names. In Section 5.5 we outline an extension to our
typing system that will enable the consistency of resource types to be maintained
across different domains.

The treatment of the alternative server s
LmemSVbis is very similar. Ignoring

the residual client behaviour, in order to establish

req  s
LmemSVbis | c1
Clientbis1 (m1 ) | c2
Clientbis2 (m2 )

it is sufficient for req to have as an entry for the request channel req the type
rw M, w@loc
.

As a final example in this section let us re-emphasise the use of typed channels
to implement the selective distribution of capabilities, already touched upon with
aPi in Example 3.15.

Example 5.19 [Distributing Capabilities ] We revisit the memory server of

Example 5.7, used by two clients. Let us assume that the overlall system has reached
the stage

Sys ⇐ (new m1 : M)(m1
LMem | c1
C1 (m1 )) | bob
codeB |

(new m2 : M)(m2
LMem | c2
C2 (m2 )) | jane
codeJ (5.31)

where for convenience we ignore the presence of the actual server, and assume the
presence of friends bob and jane. Only c1 knows about the memory m1 , which it
158 A distributed asynchronous pi-calculus

uses in the code C1 (m2 ), while only c2 knows about m2 , which it uses in C2 (m2 ).
Let us see how bob and jane are informed aboout these new memories.
One possible instantiation of their respective codes is given by:

C1 (m) ⇐ goto bob.xpt1 ! m1

C2 (m) ⇐ goto jane.xpt2 ! m2

codeB ⇐ xpt1 ?(x) B(x)

codeJ ⇐ xpt2 ?(x) J(x)

The channels xpti are used by the clients to inform bob and jane of these resources;
the first client exports the name of its private cell m1 to bob using xpt1 while the
second uses xpt2 to inform jane of m2 . Using the reduction semantics one can show
that Sys may evolve to

Sys1 ⇐ (new m1 : M)(m1
LMem | bob
B(m1 )) |

(new m2 : M)(m2
LMem | c2
J(m2 ))

The question now is what resources at mi can bob and jane use in Sys1 ; that is
what resource access have they achieved at these sites?
This of course depends on the type environment used for (5.31). Here we assume
that M is the type

loc[put : rw Tp
, get : rw Tg
]

as discussed in Example 5.18, and let bj contain the entries xpt1 @bob : rw Mp

and xpt2 @jane : Mg , where Mp , Mg denote loc[put : w Tp

] and loc[get : w Tg
]
respecively, both of which are supertypes of M. By demanding that

bj  Sys (5.32)

we are enforcing the access policy that bob has only write access on put at m1
and that jane has only write access on get at m2 . For example establishing (5.32)
requires, among other things,

bj , x:Mp
bob B(x)

that unravels to

bj , x : loc, put@x : w Tp

bob B(x)

Since x is fresh to bj , in the code B(x) the only resource available at the location
x is put, and this can only be used with the capability w Tp
.

 5.3 Subject reduction for aDpi 159

5.3 Subject reduction for ADPI

The object of this section is to show that the approach to establishing subject
reduction for aPi, in Section 3.4.3, which in turn is based on Section 3.3, can be
adapted to aDpi. There are however some complications:
(1) In aDpi there are three different kinds of typing judgements, for values, agents and
systems, in addition to the judgements for well-formed environments.

This is not a major issue; computations are essentially carried out by agents and
therefore we concentrate on these judgements. In particular we need to develop
substitution results, similar to those in Proposition 3.9 for agents; these of course
will rely on similar results for values.
(2) Typing judgements for both agents and values are relative to locations, with judgements
of the form  k P and  k V : T respectively.

This means that our substitution results have to take into account both the location
of the judgement being made and the location of the value being substituted, which
may be different.
(3) (Interchange), as in Proposition 3.7, does not hold in aDpi.

As an example if both k and c are new to  we have

, k : loc, c@k : C k c : C
but obviously we cannot derive
, c@k : C, k : loc k c : C
for the simple reason that the result of switching the entries, , c@k : C, k : loc, is
not a valid environment.
Although this seems like a minor property to get worried about, it was used
extensively in the proof of the substitution result for aPi, Proposition 3.9, at least
for (processes). See for example the case (sty-in) given there; but it is also required
for the case (sty-new). What this means is that the statement of the corresponding
substitution results for aDpi will have to be much more general; this has already
been explored in the questions at the end of Chapter 3.
Let us first adapt the sanity checks given in Lemma 3.5 for aPi to aDpi.
Lemma 5.20 (sanity checks for ADPI)
(i) ,    env implies   env
(ii)  w u : E implies   env and   w : loc
(iii)  w R implies   env
(iv)   M implies   env.

Proof: In each case a simple proof by rule induction suffices.

160 A distributed asynchronous pi-calculus

Recall that for aDpi valid type environments  can contain entries of the
form u : E or u@w : E, and consequently dom() will in general be a finite
set of compound identifiers. Nevertheless modulo this slight complication, the
interpretation of environments as functions from their domain to types given in
Definition 3.25 carries over. Extending the notation used there, we let {e}, for any
e in dom(), denote the non-empty set of types E such that e : E occurs in .
Lemma 5.21 Suppose   env . Then
• e ∈ dom() implies {e} ↓
• u ∈ dom() implies   u : ({u})
• u@w ∈ dom() implies  w u : ({u@w}).

Proof: Note that here, in the second clause, we are using the abbreviated form of
typing judgements for global types, justified by Lemma 5.11, where the location
subscript is omited from typing judgements. If a simple identifier u is in dom(),
then it will have associated with it a global type; specifically this can only be loc
or a base type.
The proof is a straightforward adaptation of that of Lemma 3.24, to the notation
for located judgements.

This allows us to generalise Definition 3.25 to aDpi environments:

Definition 5.22 (environments as functions) For every e in the domain of , we
use (e) to denote the type ({e}).
We also borrow the associated notation, such as  r (e) and  w (e), from
Definition 3.25. 

The properties of value typing for aPi, given in Proposition 3.26, also generalise
in the natural manner:
Proposition 5.23 In aDpi
(i)   u : A implies (u) exists, and (u) <: A
(ii)  w u : C implies (u@w) exists and (u@w) <: C
(iii)  w u : r T1
and  w u : w T2
implies T2 <: T1
(iv)  w V : T1 and  w V : T2 implies T1  T2 exists and  w V : (T1  T2 )
(v) (subsumption)  w V : T1 and T1 <: T2 implies   V : T2 .

Proof: A simple adaptation of the corresponding results for typed aPi, in

Proposition 5.23. Note that in (i) we could just have written (u) = A because
of the limited possibilities for the type A; it can either be a base type or loc.

Let us now check that apart from (interchange) most of the properties for
capabilities typing given in Section 3.4.3 carry over. As usual we will leave the
detailed proofs to the reader, and be content to lay down the sequence in which
 5.3 Subject reduction for aDpi 161

the various results can be established. We adapt the method used to compare type
environments from the previous chapter, in Definition 3.27.
Definition 5.24 (comparing environments) For valid type environments let 1 <:
2 if for every identifier w, 2 w u : E implies 1 w u : E. As in Section 3.4 we
write 1 ≡ 2 whenever 1 <: 2 and 2 <: 1 . 
To state uniformly results for both value and agent judgements, let us write  w
J : G to denote either of these kinds of judgements,  w V : T or  w R : proc.
Then
Proposition 5.25
• (Weakening)  w J : G and   <:  implies   w J : G.
• (Environment strengthening) Suppose , e : E,   env, where bn(e) does not occur in
. Then ,   env.
• (Strengthening) Suppose , e : E,  w J : G, where bn(e) does not occur in , w, J
or G. Then ,  w J : T.

Proof: The proof of (weakening) is by rule induction, with a (long) case analysis of
the last rule used. That of (environment strengthening) is by induction on the size
of . The case when this is empty, the base case, is an instance of the first part of the
(sanity checks), Proposition 5.20 above. Otherwise it has the form  , e : E and
again the (sanity checks) ensure that , e : E,   env. So by induction ,   env.
We now have to argue that this can safely be extended by e : E . There are four
possible cases, and each in turn follows by virtue of the fact that , e : E,  can be
safely extended by e : E . For example if e : E is u@w : C then we have to show
that if ,  w u : C then C ↓ C . But by (weakening) ,  w u : C implies
, e : E,  , u@w : C w u : C and therefore the required C ↓ C follows from part
(iv) of Proposition 5.23.
Finally (strengthening) is once more a long rule induction proof, with the
various base cases, such as the application of (ty-c.sub), (ty-zero), relying on the
just established (environment strengthening). Let us examine one inductive case.
Suppose
, e : E,  w (new c : C) R
because
, e : E, , c@w : C w R
Then we are assured that bn(e) does not appear in (, c@w : C), and therefore we
can apply induction to obtain
, , c@w : C w R
An application of (ty-cp.new) gives the required ,  w (new c : C) R.

162 A distributed asynchronous pi-calculus

Note that this version of (strengthening) is somewhat more general than that stated
in Proposition 3.30 for typed aPi; the generality means that it does not require any
interchange property.
As we have already indicated, we do not have an interchange law for typing
judgements. 1 , e1 : E1 , e2 : E2 , 2 w J : G does not necessarily imply 1 , e2 :
E2 , e1 : E1 , 2 w J : G because 1 , e2 : E2 , e1 : E1 , 2 may not be a valid type
environment. However there are certain constraints on e1 , e2 , which ensure that
they can be safely interchanged. One is given in the following lemma, although
there are valid exchanges not covered by it; see Question 6 at the end of the chapter.

Proposition 5.26 (partial interchange) Suppose , e1 : E1 , e2 : E2  env, where e1

does not occur in e2 . Then
(i) , e2 : E2 , e1 : E1  env
(ii) , e1 : E1 , e2 : E2 ≡ , e2 : E2 , e1 : E1 .

Proof: The first result requires a tedious analysis of the possible forms of e1 : E1
and e2 : E2 ; in each case we have to first argue that , e2 : E2  env, and then argue
that it can safely be extended by the entry e1 : E1 . For example suppose e1 : E
is w : loc and e2 : E2 is u @w : C. Then since w must be different from w, the
reason for being able to safely extend , e1 : E1 with e2 : E2 , an application of
(e-chan), applies equally well to , and so we have , e2 : E2  env. The extension
to , e2 : E2 , e1 : E1 is now justified by an application of (e-loc).
The second result is a straightforward proof by rule induction, as typechecking
essentially still uses environments as lookup tables, despite the presence of multiple
entries for identifiers.

This exchange can be extended from single type association entries to the more
general extensions given in Definition 5.12; we confine our attention to the global
version of this notation.

Corollary 5.27 Suppose , e1 :A1

, e2 :A2
 env. Then , e2 :A2
, e1 :A1

env, provided bn(e1 ) does not occur in e2 : A2 .

Proof: A case by case analysis is required of the types Ai . The case when both
are channel types is covered by the previous proposition (partial interchange), and
when they are base types the proof is straightforward. The non-trivial case is when
either are location types. The requirement that bn(e1 ) occurs neither in e2 nor in
the type A2 , ensures that even in this case (partial interchange) can be applied;
in general multiple applications will be required.

These permitted forms of interchange are not sufficiently general to allow the
straightforward transfer of the substitution results from aPi to aDpi. But they
 5.3 Subject reduction for aDpi 163

do come into play when showing that structural equivalence is preserved by

typing:
Proposition 5.28 Suppose M ≡ N . Then   M if and only if   N.
Proof: The proof proceeds as in Proposition 3.11, by induction on why M ≡ N ,
and as with that proof, the only non-trivial part is dealing with the axioms, from
Figure 5.5. The most important axiom is (s-extr) but the proof is virtually identical
to the aPi case.
So instead let us consider briefly (s-flip). Suppose   (new e1 : D1 )
(new e2 : D2 ) M , where bn(e1 ) does not occur in e2 : D2 . The only way this
judgement can be established is by applications of (ty-cnew) or (ty-lnew),
depending on the form of the types, to the judgement , e1 :D1
, e2 :D2
 M .
The side-condition means that we can apply the previous corollary to obtain
, e2 :D2
, e1 :D1
 M , to which the rules (ty-lnew) and (ty-cnew) can again
be applied, to obtain the required   (new e2 : D2 ) (new e1 : D1 ) M .
Finallyconsiderthesecondrulein(s-zero).  0istrueforanyvalidenvironment
. But so is   k
stop, as this only requires that  k stop; note that this latter
judgement does not actually require k to be known as a location in .

Let us now turn our attention to the substitution results, which are a central
component of subject reduction. As we have already explained these will be
somewhat more complex than for aPi, because of the lack of (interchange). The
complexity occurs because we have to consider not only substitutions into values
and processes, but also environments. First let us look at value judgements.
Proposition 5.29 (substitution for values) Suppose  w1 v : A, and that
, x:A
@w1 ,  w2 u : B, where x is fresh to . Then, assuming , {|v/x|}  env, it
follows that , {|v/x|} w2 u{|v/x|} : B, where w2 denotes w2 {|v/x|}.
Proof: Here  is a list of type associations, and {|v/x|} is the result of substituting
each occurrence of the variable x in  with v. But note that variables cannot occur
in types, and therefore in effect the substitutions only take place in the compound
identifiers in . Also note that the locations w1 and w2 need not be the same, and
that for the sake of clarity we use B to range over an arbitary value type.
The proof is by induction on the inference of , x:A
@w1 ,  w2 u : B, and
an examination of the last rule used; throughout we use the notation J  as in
Proposition 3.9, to denote the substitution J {|v/x|}, for any syntactic category J .
As an example suppose (ty-c.sub) is the last rule used; this may be applied to
an occurrence of u@w2 : Bs , for some subtype Bs of B, which may appear in ,
in , or in the list x:A
@w1 . In the first case we know that  w2 u : B and an
application of (weakening), from Proposition 5.25, gives ,  w2 u : B and the
required result follows because we know both w2 and u must be different from x.
164 A distributed asynchronous pi-calculus

If on the other hand u@w2 : Bs occurs in  then u @w2 : Bs naturally occurs in  ,

which justifies the judgement ,  w2 u : B. Finally suppose it occurs somewhere
in the list x:A
@w1 . Here we do an analysis on the type A. Note that since v is a simple
value the type A can only be either a base type base, a located channel type C or a
location type K; we leave the case when it is a base type to the reader.
• A is a local channel type C. Then x:A
@w1 unravels to x@w1 : C, and the inference
must be
, x@w1 : C,  w1 x : B
where C <: B; note that here w2 coincides with w1 , and is different from x. But one of
our assumptions is that  w2 v : C, and therefore the required result, ,  w2 v : B,
follows by (weakening) in Proposition 5.25 and (subsumption) in Proposition 5.23.
• A is the location type K = loc[a1 : C1 , . . . an : Cn ]. Here x:A
@w1 unravels to x :
loc, a1 @x : C1 , . . . , an @x : Cn and there are two cases. The lookup may be a use of
(ty-loc.sub) to infer the judgement , x:A
@w1 ,  w2 x : loc, which we leave to the
reader. Otherwise it takes the form , x:A
@w1 ,  x ai : Ci for some Ci <: Ci ; here
w2 coincides with x. Again we rely on the assumption  w1 v : K, from which we
obtain  v ai : Ci . So once more the required result follows from (weakening) and
(subsumption).

This ends our analysis of the case when (ty-c.sub) is the last rule used. There
are seven other cases to consider, corresponding to each of the possible rules in
Figure 5.9. But all are either a case analysis, much simpler than the one we have
just done, or follow trivially by induction.

In this result the premise that , {|v/x|} is a valid environment is unfortunately

required, as environment formation is not necessarily preserved by substitution.
Example 5.30 Let Rr , Rw denote the local channel types r r
, r w
respectively;
note that Rr ↓ Rw . Also let T denote the type rw r
, and here note that T <: Rr but
T  ↓ Rw .
Now let the environment  be simply the two type associations k : loc, c@k : T,
and  be the single type association x@k : Rw . Then
 k c : Rr
, x@k : Rr ,  k x : Rr  Rw
The first follows by an application of (ty-c.sub), whereas the second uses two
instances of this same rule followed by an application of (ty-meet). But note that
here it is essential that , x@k : Rr ,   env. However we cannot conclude
, {|c/x|} k c : Rr  Rw
for the simple reason that the type association list , {|c/x|} is not a well-formed
environment. This is a consequence of the fact that T ↓ Rw .

 5.3 Subject reduction for aDpi 165

We can now extend this generalised substitution result from value judgements,
Proposition 5.29, to agent judgements:
Proposition 5.31 (simple substitution for agents) Suppose  w1 v : A and x is
fresh to . Then provided , {|v/x|} is a valid environment, , x:A
@w1 ,  w2 R
implies , {|v/x|} w2 R{|v/x|}, where w2 denotes w2 {|v/x|}.
Proof: This follows the lines of the proof of Proposition 3.9, using induction on
the derivation of the judgement , x:A
@w1 ,  w2 R, but the details are somewhat
more subtle. We examine three cases; as usual we use the shorthand notation J  for
J {|v/x|}.
Suppose , x:A
@w1 ,  w2 u?(Y ) R because
(i) , x:A
@w1 ,  w2 u : r T

(ii) , x:A
@w1 , , Y :T
@w2 w2 R

for some type T. In other words (ty-in) was the last rule used in the inference. Now
we are assuming ,   env, and therefore we may apply Proposition 5.29 to (i) to
obtain
(i’) ,  w
2
u : r T
.

Since all the variables in the pattern Y can be assumed to be fresh we also have
that ,   env implies ,  , Y :T
@w2  env. This latter environment is actually
, (, Y :T
@w2 ) , which means that we can apply induction to (ii) to obtain
(ii’) ,  , Y :T
@w2 w
2
R .

So (ty-in) can now be applied to (i’) and (ii’) to obtain the required ,  w2 R .
Note that this case, unlike in the proof of Proposition 3.9, we did not need to apply
any (interchange).
The case when (ty-lp.new) is the last rule used is similar. Here we have
, x:A
@w1 ,  w2 (newloc k : K) R
because , x:A
@w1 , , k:K
w2 R. As before, we can assume k is fresh and
therefore ,  , k:K
is a well-formed environment; moreover it coincides with
, (, k:K
) . Therefore applying induction we get ,  , k:K
w2 R . A final
application of (ty-lp.new) gives the required result.
Let us now examine the most interesting case. Suppose (ty-match) is the last
rule used. So
, x:A
@w1 ,  w2 if v1 = v2 then R1 else R2
because for some types A1 , A2
(i) , x:A
@w1 ,  w2 v1 : A1
(ii) , x:A
@w1 ,  w2 v2 : A2
166 A distributed asynchronous pi-calculus

(iii) , x:A
@w1 ,  w2 R2
(iv) , x:A
@w1 , e w2 R1

where e is a notation for , v1 :A2

@w2 , v2 :A1
@w2 . Again since we are assuming
,   env we may apply Proposition 5.29 or induction to obtain
(i’) ,  w
2
v1 : A1
(ii’) ,  w
2
v2 : A2
(iii’) ,  w
2
R2 .

If , (e )  env then we can also apply induction to (iv) to obtain

(iv’) ,  , v1 :A2
@w2 , v2 :A1
@w2 w
2
R1 .

Then (ty-match) can be applied to (i’)–(iv’) to obtain the required

,  w
2
if v1 = v2 then R1 else R2 (5.33)

So let us consider the possibility that , (e ) is not a valid environment; note that
here we can assume that v1 and v2 are different, as otherwise , (e ) ≡ ,  . We
show that (ty-mis.match) can be applied to obtain (5.33), although not necessarily
with the types A1 , A2 used above in (i), (ii).
Now , (e ) unravels to ,  , v1 :A2
@w2 , v2 :A1
@w2 and there are only
two reasons why it might not be a valid environment, although ,  is.
• Suppose ,  , v1 :A2
@w2   env. Here A2 cannot be a base type, and so we can apply
the extension lemma, Lemma 5.13. This means that there must exist some type A such
that A ↓ A2 and  w2 v1 : A. So we can use this, together with (ii’) and (iii’) above, as
premises to (ty-mis.match) to obtain the required (5.33).
• So we can assume ,  , v1 :A2
@w2 is a valid type environment and therefore another
application of the extension lemma gives a type B such that B  ↓ A1 and ,  ,
v1 :A2
@w2 w2 v2 : B. But since v1 and v2 are different this actually means that ,
 w2 v2 : B, which again allows us to apply (ty-mis.match) to obtain the result.

Corollary 5.32 (substitution for agents) Suppose  w1 V : T and all variables in
X are fresh to . Then , X :T
@w1 w2 R implies  w2 R{|V/X |}, where w2 denotes
w2 {|V/X |}.
Proof: By induction on the structure of the pattern X . The base case, when it is a
simple variable, is given in the previous proposition. So suppose it has the located
form x@y, in which case the type T must be of the form C@loc, and the value V of
the form v @w.
So we know, by unravelling the environment,
, y : loc, x1 @y : C w2 R
 5.3 Subject reduction for aDpi 167

But  w1 V : T means that   w : loc, and the freshness of x ensures that
, x@w : C is a valid environment. So we may apply the previous result to obtain
, x@w : C w2 R{|w/y|}
where w2 denotes w2 {|w/y|}. But  w1 V : T also means that  w v : C, and since
this latter environment has the form , x:C
@w the result can be applied again to
obtain  w2 (R{|w/y|}){|v/x|}, where w2 denotes w2 {|v/x|}. But this is the required result
since w2 is w2 {|V/X |} and (R{|w/y|}){|v/x|} is R{|V/X |}.
The final case, when X is the pattern (X1 , . . . , Xn ) is handled in a similar
manner, assuming by induction that the result already holds for the individual
components Xi .

We need one more substitution result, to handle recursion.

Proposition 5.33 Suppose  w R1 and , x@w : proc,  w R2 . Then R2 {|R1/x|} is
well-defined and ,  w R2 {|R1/x|}.
Proof: This is a generalisation of Proposition 3.9 (recursion), but with the
judgements now local to a site w. The proof proceeds by induction on the inference
, x@w : proc,  w R2 .
The base case is when this uses the rule (ty-proc.sub) from Figure 5.9; the
inference is therefore
, x@w : proc,  w x
and the result is given by (weakening) from the premise  w R1 .
All other cases follow in a straightforward manner. Note however that the case
when (ty-match) is the last rule used requires the more general form of the result,
involving , rather than the simple form, as in Proposition 3.9 (recursion).

We have now accumulated all the auxiliary results required for subject reduction.
Theorem 5.34 (subject reduction for ADPI) Suppose M −→ N , where M , N are
systems in aDpi. Then   M implies   N .
Proof: The proof is by induction on the derivation of M −→ N . As in the proof of
Theorem 3.12 we can concentrate on the defining rules, given in Figure 5.5. The
rule (r-str) has already been covered by Proposition 5.28 and so we look at some
of the defining axioms.
Consider the axiom (r-comm). By the hypothesis we know
  k
c! V
 | k
c?(X ) R (5.34)
and we have to prove
  k
R{|V/X |}
168 A distributed asynchronous pi-calculus

that will follow if we can prove

 k R{|V/X |} (5.35)
Dissecting the premise (5.34) we know that
 k V : T1
 k u : w T1

 k u : r T2

, X :T2
@k k R
for some types T1 and T2 . Here we can apply part (iii) of Proposition 5.23 to
deduce T1 <: T2 . Then (subsumption), the final part of the same proposition, gives
 k V : T2 and we have the required hypothesis of Corollary 5.32, with  being
the empty environment, to conclude (5.35) above.
The proofs for the two creation rules, (r-l.create) and (r-c.create) are
very similar and rely on the relationship between the typing rules for systems,
(ty-cnew), (ty-lnew) in Figure 5.10, and the corresponding rules for agents in
Figure 5.11, (ty-cp.new) and (ty-lp.new). As an example consider the rule for
location generation
(r-l.create) k
(newloc l : L) P  −→ (new l : L) k
P 
and suppose   k
(newloc l : L) P . This means  k (newloc l : L) P, which
can only be inferred using the rule (ty-lp.new) from , l:L
k P. But this implies
, l:L
 k
P , which is the premise required for an application of (ty-lnew) with
the conclusion
  (new l : L) k
P 
Now consider the rule (r-eq); from
 k if v = v then P else Q (5.36)
we have to prove  k P. This judgement cannot be derived from an application of
(ty-mis.match); this would require two types Ai such that A1  ↓ A2 and
 k v : Ai
which contradicts part (iv) of Proposition 5.23. So (5.36) can only be derived using
the rule (ty-match), in which case we have
, v:A1
@k, v:A2
@k k P
for some types Ai such that  k v : Ai . But here it is easy to show that
, v:A2
@k, v:A2
@k ≡ 
from which the required  k P follows.
 5.4 Type safety for aDpi 169

The remaining rules are straightforward. In (r-neq) we have to prove  k Q

from
 k if v1 = v2 then P else Q
But  k Q is a hypothesis to each of the possible rules, (ty-match) or
(ty-mis.match), which can be used to establish this. The case (r-move) follows
from (ty-agent) and (ty-go), while the argument for (r-unwind) is similar
to that used in Theorem 3.12, but using the appropriate substitution result,
Proposition 5.33.

5.4 Type safety for ADPI

Here we review the purpose of the type system we have developed for aDpi and
examine the extent to which it fulfils our expectations.
In Section 3.1 it was argued that one purpose of a type system is to eliminate
runtime errors in programs, and one definition of such errors for aPi was given in
Figure 3.1; essentially errors occur either when an attempt is made to use a value
inappropriately; for example attempting to input or output on a value that does not
represent a channel, or attempting to match a structured value against a differently
structured pattern.
In extending this definition to aDpi a subtlety arises. Let us consider the rule
(err-chan) from Figure 3.1; this states that, for example, v! V
contains a runtime
error if v is not a name. So 3! V
contains a runtime error but n! V
does not, for
any name n. This is because in aPi all names are assumed to be channel names;
indeed there is no other syntactic construct to name. However, turning to aDpi, it
is not so clear when
k
n! V
 (5.37)
contains a runtime error. Recall that n can come from the set of names Names, and
a priori there is no indication whether it represents a channel or a location; although
informally we have been using a, b, c, . . . as channel names and l, k, . . . as location
names the set Names actually contains an undifferentiated set of names. In other
words we can only tell if (5.37) contains a runtime error relative to some prescribed
intended use of each of the names in Names.
Rather than get side-tracked in setting up appropriate definitions for this concept
let us just use type environments for this purpose, although these prescribe the
intended use of names in much more detail than we require here. In other words
we define a relation
M −→err 
indicating that M contains a runtime error, from the point of view of the intended
use of names as described in .
170 A distributed asynchronous pi-calculus

Figure 5.12 Runtime errors in aDpi

The definition is given in Figure 5.12 and is modelled directly on that of

Figure 3.1, although the presence of  allows us to be more specific in describing
the cause of errors. The rule (err-loc) states that k
goto v.R contains a runtime
error, from the point of view of , if v is not considered to be a location. The rules
(err-read) and (err-write) are a generalisation of (err-name) from Figure 3.1;
for example the latter states that k
v! V
 contains an error if v is not known by 
to be a channel at k on which there is a write capability. The remaining rules are the
obvious adjustments of the corresponding ones in Figure 3.1 to the syntax of aDpi.
But it is worthwhile noting that the relation is not quite contextual; the second part
of (err-cxt) requires an extension to  in its premise.
It is now a straightforward matter to show that our type system for aDpi eliminates
the possibility of runtime errors, thus defined. This is the obvious extension of the
corresponding result for aPi in Chapter 3 for aPi, Corollary 3.14.
Theorem 5.35 (simple type safety for ADPI) Suppose   M . Then M −→∗ N
implies N  −→err
.
Proof: By subject reduction, Theorem 5.34, we know that   N . Therefore we
need only adapt the proof of Theorem 3.13 to show that this in turn implies that
N  −→err
 ; in fact we prove the contra-positive, that N −→ implies that   N
err

cannot be derived, by induction the derivation of N −→err.

As an example suppose k
goto v.R −→err  because    v : loc. Now the only
possible way to infer   k
goto v.R is via an application of (ty-agent) to
 k goto v.R. But this in turn can only be derived via an application of (ty-go),
which requires the impossible   v : loc.
 5.4 Type safety for aDpi 171

As another example suppose (new e:D) M −→err  because M −→, e:D

. By
err

induction we have , e:D

 M . But the only way of inferring   (new e:D) M
is by an application of one of the creation rules, (ty-cnew) or (ty-lnew) from
Figure 5.10, all of which require the appropriate instance of , e:D
 M .

However our typing system does much more than enforce the proper use of
location and channel names. In the introduction to Section 5.2 we have proposed it as
a mechanism for controlling capabilities on names, and therefore for implementing
access control policies on domains. This idea was briefly alluded to at the end of
Chapter 3, and now we explain it in detail. This is best approached via an example.
Example 5.36 Let us revisit Example 5.19 where clients have used the memory
server to obtain their private instances of located memory cells; this in turn is based
on Example 5.18 and the related Example 5.7. Here we consider the following
variation:
Sysb ⇐ bob
codeB | (new m : M)(m
LMem | c
C(m)) (5.38)
where M is the type loc[put : rw Tp
, get : rw Tg
] and
codeB ⇐ xptp ?(x) B(x)
C(m) ⇐ goto bob.xptp ! m

The client c makes available the existence of its private memory cell m to bob
along the channel xptp . Moreover, as already explained in Example 5.19, it is
made available with restricted access rights. Using the reduction semantics Sysb
evolves to
Sysb1 ⇐ (new m : M)( bob
B(m) | m
LMem ) (5.39)
where, as we have seen, the resource capabilities at m accessible to bob are
determined by the write capability on the export channel xptp .
Suppose b contains the entries
. . . , xptp @bob : rw Mp
, print @bob : rw int
, . . .
where Mp is loc[put : w Tp
], a supertype of M. Thus, as explained in Example 5.19,
intuitively b enforces the access policy in which bob has only write access on put
at m. Yet, as we shall see, type safety, based on the runtime errors of Figure 5.12, is
largely independent of the actual instantiations of B(x) in (5.38) above. For example
with
B(x) ⇐ (newc r : R) (r?(y) print! y
| goto x.get! r @bob
)
the original system, Sysb from (5.38), is type safe, assuming R is correctly
instantiated; that is no runtime errors can occur, relative to b . Formally one can
show that S −→err b ∗
b for every S such that Sys −→ S.
172 A distributed asynchronous pi-calculus

An obvious S to worry about is

S ⇐ (new m:M)((new r:R)(bob
r?(y) print! y

| m
get! r
) | m
LMem) (5.40)
where bob has received the name m at the type Mp , but nevertheless has sent an
agent there to collect the value in the memory via the method get. However one
can check that there is no runtime error here; that is S  −→errb . For S −→err
b could
only be derived by applications of (err-cxt), which would require
m
get! r
 −→err
b , m:M
, r:R

However this is not possible since in the extended environment there is a write
capability on get at m.
Thus the notion of runtime error is not sufficiently discriminating to pick up this
misuse of capabilities by bob. Nevertheless the type system was designed to forbid
such misuses, and one can show that
b  Sysb
The problem arises when trying to establish b bob xptp ?(x) B(x). Because of the
type of xptp at bob in b this requires deriving

be x get : w Tg

where be is an extension of b in which the only entries involving x are x : loc and
put : Tp @x.

This example demonstrates that, although the type system does enforce some form
of constraints on the capabilities available to agents, the current notion of runtime
error is incapable of describing these constraints. In order to capture the power of
the type system in an independent manner we need a version of the language in
which the capabilities obtained by agents are explicitly described.
In the next section we describe such a language, tagged-aDpi. With this explicit
representation of agent capabilities, it will be straightforward to define a version of
runtime error that represents more clearly the misuse by agents of their acquired
capabilities.
This is followed by a further section in which we explain how properly typed
aDpi systems may be interpreted as tagged systems. Moreover these tagged systems
will be guaranteed to be free from tag-based runtime errors. In other words the type
system for aDpi alleviates the user from explicitly programming and reasoning
about an agent’s capabilities.
 5.4 Type safety for aDpi 173

5.4.1 TAGGED-ADPI
It may seem rather daunting to embark on the definition of a new language, with
its associated reduction semantics and typing system. But the only new construct
we actually need is a representation of the capabilities, or permissions of agents.
For this we employ the syntax

k
P 

where  is a list of type associations; this represents the agent P running at location
k, with the permissions given in . So the syntax of tagged-aDpi is given by simply
replacing the syntax for systems, in Figure 5.2, with that given in Figure 5.13; we
use Mt , Nt as meta-variables for tagged systems, in order to distinguish them from
untagged systems of aDpi. Formally here  simply ranges over association lists
between names and types. Although much of the technical development of this

Figure 5.13 Tagged aDpi

174 A distributed asynchronous pi-calculus

section will only make sense when  is actually a valid type environment, in
examples we will be less demanding. It is also worth noting that the definition
allows the formation of tagged systems such as
(new k:K)(l
P 1 | k
P 2 )
where the bound name k may appear in either or both of the capability descriptions
1 , 2 .
This new language tagged-aDpi needs to be endowed with a new reduction
semantics, describing the manner in which agents acquire new capabilities. As we
have already indicated these are required as a result of a communication between
two agents; after the communication of a value V along a location channel c at
location k, the receiver obtains the capabilities on the values V ordained by its
current read capabilities on c at k. To formalise this concept we use the notation
developed in Definition 5.22 for interpreting environments as partial functions from
compound identifiers, to types.
Let us consider the two agents
k
c! v
1 | k
c?(x) P 2
co-located at k. The first is willing to send a simple value v on c, while the second
is waiting to receive a value on it. The latter’s ability to use c is determined by its
current capabilities, described in 2 . So for example if there is no read capability on
c at k in 2 then the communication is not possible. If there is, the communication
can happen and moreover the capabilities received on v are determined by the read
capability on c at the site k in 2 . After the communication the receiving agent,
and its capabilities, are described by
k
P{|v/x|}2 , v:r2 (c@k)
@k
The value v may already be known in 2 , in which case extra capabilities on it have
been acquired, or it may have been a completely unknown value, in which case it
is now known by the receiver, and may be used in accordance with the capabilities
described in v:r2 (c@k)
@k; this represents the capabilities that the receiving agent
can acquire using the channel c at k, according to its current permissions 2 .
Formally the reduction semantics is given as a binary relation between tagged
systems
Mt −→t Nt
which is the least contextual relation satisfying the axioms and rules given in
Figure 5.13. The main rule is (rt -comm), which we have just described in detail, at
least for simple values. This axiom is interpreted to only hold when V :r2 (c@k)
@k
is well-defined; that is, whenever it unravels according to Definition 5.12 to a list
 5.4 Type safety for aDpi 175

of type associations. So at the very least r2 (c@k) is required to exist, but it must
also match the structure of the value V .
The remaining rules are inherited directly from the reduction semantics of aDpi,
in Figure 5.5. Note that in (rt -move) agents retain their capabilities as they
move between domains; also in the housekeeping move (rt -split) capabilities
are preserved as agents divide in preparation for communication or migration.
The rules for newly created names, (rt -c.create) and (rt -l.create), need to
update the agent’s tag with the declared capabilities on the newly created name.
The remaining rules are omitted, as the reader can reconstruct them directly from
Figure 5.5. Of course (rt -str) requires a structural equivalence between tagged
systems; its definition is in turn inherited from that for aDpi, in Figure 5.4; the only
change required is to replace the untagged k
stop in the axiom (s-zero) with its
tagged version k
stop .
Example 5.37 [Tagged Systems ] Consider the following variation on the system
described in Example 5.36:
j
Syst ⇐ jane
codeJj | (new m : M)(m
LMemm | c
C(m)c ) (5.41)
where this time we have the code
C(m) ⇐ goto jane.xptp ! m

codeJ ⇐ xptp ?(x) (new r : R) goto x.put! 7, r @jane

with R the type appropriate to a reply channel being sent on put, namely rw. Of
course in a complete example jane would not only put the value (7, r @jane) into
the memory but would continue computing on receipt of an acknowledgement on
r; but for simplicity we ignore this continuation. Suppose further that the current
capabilities of jane and the client are
c : xptp @jane : w Mp
, m : loc, put@m : Tp , get@m : Tg
j : xptp @jane : r Mp

Then a contextual application of (rt -move), followed by (rt -str), gives

j
Syst −→t (new m : M)( jane
codeJj | jane
xpt! m
c | m
LMemm )
At this point note that the agent emanating from the client, jane
xpt! m
c has
both put and get capabilities at m, as evidenced in its set of permissions c . On
the other hand jane still has no permissions at m, as evidenced in j , although it is
within the scope of the declaration of m at type M.
But we can make a contextual application of (rt -comm) to obtain
(new m : M)( jane
(new r : R) goto m.put! 7, r @jane
1 | m
LMemm )
j
176 A distributed asynchronous pi-calculus

where now the capabilities of jane are given by

1j = j , m:loc, put@m:w Tp

This is because m:Mp

@jane, the new capabilities acquired during the com-
munication, unravels to m : loc, put@m : w Tp
, by applying Definition 5.12.
Then an application of (rt -c.create) followed by one of (rt -move) gives
(new m : M) (new r @jane : R)( m
put! 7, r @jane
2 | m
LMemm )
j

Here the migrating agent has acquired the declared permissions on the newly
generated reply channel r; 2j represents

1j , jane:loc, r @jane:rw

Now, assuming m has a read capability on put in its current capabilities m , a
communication can happen along put, as a consequence of which m will acquire
some capability on r at jane. If, as expected, m contains the entry put:rw Tp
,
then it will acquire the new capability (7, r @jane):Tp
@m. Since Tp is (int, w@loc)
this unravels to jane:loc, r @jane:w; the memory has acquired the permission to
write an acknowledgement along r at jane.

Typechecking tagged-aDpi: Our reduction semantics for tagged-aDpi appears

to correctly implement the informal idea of the selective distribution of capabilities
via typed channels. However there are problems; the agent on the receiving end of
a communication obtains the capabilities dictated by the communication channel,
even if these are not owned by the sender.
Example 5.38 Consider the system
Sys ⇐ l
goto k.in! s
l | k
in?(x) goto x.info! news
k
Here l informs k of an information gathering service at s; k goes there and sends
some news along a channel info, which it knows should be available at s.
Suppose l and k both contain the permission in@k : rw loc[info : w str
]
.
So both sites have permission to use in at location k for transmitting locations of
type loc[info : w str
]. Suppose further, for the sake of argument, that these are
the only permissions in l and k ; note that this implies that l has no permissions
for the site s.
According to our semantics we obtain the reductions
Sys −→t k
goto s.info! news
nk
where nk is the updated set of permissions , s:loc, info@s:w str
; the agent k has
gained permission to use info at s, despite the fact that l did not have this permission
to pass on; indeed this permission did not exist anywhere in the system.

 5.4 Type safety for aDpi 177

So we must restrict attention to tagged systems that are in some sense consistent;
there must be some coherency between an agent’s code and its permissions. There
are further issues, concerning consistency between the views of different agents.
Example 5.39 Suppose in the previous example that l , k are
s:loc, req@s:r str
, in@k:rw Ls

in@k:rw Ks

respectively, where Ls , Ks are loc[req : r int

], loc[info : w str
], respectively.
Here there is a fundamental misunderstanding between l and k about the type of
the channel in@k; the agent l has permission to use it for locations of type Ls , and
it uses it correctly with respect to this permission. On the other hand k believes it
is for locations of type Ks , and also uses it in accordance with this belief.
In the end, after the communication on in, k obtains a permission on s that bears
no relation to those of l; it obtains permission to use a resource info there, although
l only has permission related to a resource called req there.

To rule out these abuses of explicit permissions, and to adjudicate between

conflicting permissions of different agents we need a typing system.
The judgements of the type system for tagged-aDpi are inherited directly from
those for aDpi, and take the form
  Mt
Here, as with aDpi,  dictates the roles of the names used in Mt , and their types;
in this way inconsistencies between different agents’ permissions are eliminated.
The typechecking rules are a minor adaptation from those in Figure 5.10, the only
change being the replacement of (ty-agent) with
(tyt -agent)
 k P : proc
  env
 <: 
  k
P 
So in order for the tagged agent k
P  to be well-typed with respect to  we require
the following:
(i)  has to be a valid type environment; this is simply a sanity check on judgements.
(ii) The agent’s code P must be well-typed with respect to its permissions,  k P : proc.
This is checked using the rules for aDpi agents in Figure 5.11. Note that this will imply
that  has to be a well-typed environment.
(iii)  can only use permissions from ,  <: ; agents are not allowed to invent
permissions that do not exist.
178 A distributed asynchronous pi-calculus

Referring to Example 5.38 one can check that there is no possible  for which
  Sys can be derived. The problem occurs when trying to establish
l  l
goto k.in! s
l
This is ruled out by (ii) above, as we would need to establish
l l goto k.in! s

and l has no information of any kind about s.

Typing Example 5.39 is ruled out by condition (iii). It is possible to find a 1
and a 2 such that
1  l
goto k.in! info@s
l
2  k
in?(x) goto s.info! news
k
But there is no  such that   Sys, as this would imply
 <: l
 <: k
But this is clearly impossible because 1 and k contain conflicting type
information on in@k.
Theorem 5.40 (subject reduction for TAGGED-ADPI) In tagged-aDpi, suppose  
Mt and Mt −→t Nt . Then   Nt .
Proof: The proof is by induction on the inference of Mt −→t Nt , and most cases
are treated as in Theorem 5.34. We examine two, both instances of the axioms in
Figure 5.13.
Consider the rule (rt -move). So let us assume   k
goto l.P  , from which
we have to show   l
P  . Since the hypothesis can only be derived from an
application of (tyt -agent) we have
(i)   env
(ii)  k goto l.P
(iii)  <: .

However from (ii) we know

(ii’)  l P

and therefore an application of the same rule to (i), (ii’) and (iii) gives the required
  l
P  .
As a second example consider (rt -comm); so we know   k
c! V
1 |
k
c?(X ) R2 and we have to prove
  k
R{|V/X |}n2 , (5.42)
 5.4 Type safety for aDpi 179

where, for convenience, we have abbreviated 2 , V :r2 (c@k)

@k to n2 . From the
fact that the outputting agent is typeable relative to , we know 1 k V : w 1 (c@k),
and therefore that  k V : 1 (c@k), since  <: 1 .
w

This last fact also implies  k c : w w 1 (c@k)

, and in turn  <: 2 implies  k
c:r 2 (c@k)
. So by part (iii) of Proposition 5.23 we know w
r
1 (c@k) <: 2 (c@k).
r

By (subsumption) in the same proposition we therefore have  k V :2 (c@k), r

which is sufficient to establish that n2  env and

(i)  <: n2 .

This follows from Question 5 at the end of the chapter. Moreover since n2 is a
well-defined environment
(ii) n2 k V :r2 (c@k).

The typing of the input agent implies 2 k c?(X ) R that, by virtue of (ty-in),
means 2 , X :r2 (c@k)
@k k R. Therefore in view of (ii) the substitution result,
Corollary 5.32, gives
(iii) n2 k R{|V/X |}.

An application of the new rule (tyt -agent) to (i) and (iii) now gives the required
(5.42).

Runtime errors in tagged-aDpi : Since the capabilities or permissions of agents

are explicitly represented in tagged-aDpi, it is straightforward to define a version
of runtime error that represents the misuse of capabilities. Intuitively such a runtime
error occurs in
k
P 
if P is about to use a capability that is not in its permission set . Because we have
concentrated on two specific capabilities there are principally two ways in which
this might occur. The first is when P attempts to output on some channel c and there
is no permission to write on c at k in . This is covered by the rule (errt -out)
in Figure 5.14. The rule (errt -in) takes care of the misuse of input capabilities;
k
c?(X ) R contains a runtime error if there is no mention of a read capability on
c at k in the agent’s permissions . Formally the relation
M −→err
is defined to be the least contextual relation over tagged systems that satisfies the
two axioms (errt -in), (errt -out).
Example 5.41 Let us consider a tagged version of the system in Example 5.36:
Syst ⇐ bob
codeBb | (new m : M)(m
LMemm | c
C(m)c )
180 A distributed asynchronous pi-calculus

where b , c are given by

xptp @bob:rw Mp
, print @bob:rw int
and xptp @bob:rw Mp

respectively. Then Syst −→∗t Sysnt , where

Sysnt ⇐ (new m:M) (new r:R)( bob
r?(y) print! y
nb
| m
get! r
nb | m
LMemc )
and nb is the augmented set of permissions b , put@m:Tp . But here there is a
runtime error, in the agent m
get! r
nb , picked up by the rule (errt -out); the
agent is about to write on the channel get at m, although this resource does not
appear in its permission set nb .

Proposition 5.42 (type safety in TAGGED-ADPI) Suppose   Mt . Then Mt −→∗t Nt
implies Nt −→err .
Proof: Because of subject reduction, Theorem 5.40, it is sufficient to show Nt −→err
implies    Nt for every . The proof is by induction on the derivation of Nt −→err .
The two axioms, given in Figure 5.14, are straightforward. For example to derive
  k
c?(X ) R it is necessary, among other things, to establish  k c?(X ) R.
But this is not possible, as the side-condition on (errt -in) says that c@k contains
no read capabilities in .
The two (implicit) rules, generated by the contextuality of −→err , are handled by
induction. For example suppose (new e : D) Nt −→err because Nt −→err . Then   
Nt for no possible   . In particular , e:D
 Nt , and therefore   (new e : D) Nt
cannot be derived.

5.4.2 Types versus tags

We have just seen that tagged-aDpi is a language in which capabilities/permissions
are explicitly represented in the syntax and are explicitly managed by the runtime
semantics; moreover in well-typed systems of tagged-aDpi we are assured
that permissions are never violated by agents. However it is quite onerous on
programmers or designers to develop system descriptions in which all capabilities
are required to be explicit. Also, as we have seen, even with this explicitness a type
system is required.

Figure 5.14 Runtime errors in tagged-aDpi

 5.4 Type safety for aDpi 181

Here we show that aDpi alleviates the burden of runtime management of

these explicit tags. We explain how systems written in aDpi may be viewed as
representations for explicitly annotated systems in tagged-aDpi, and how the type
system in aDpi may be viewed as a systematic mechanism for implicitly handling
the capabilities of these annotated systems correctly.
Definition 5.43 (tagging systems) For any list of type associations  and any aDpi
system M let tag (M ) be the tagged-aDpi system defined as follows:
• tag (0) = 0
• tag (k
P) = k
P
• tag (M | N ) = tag (M ) | tag (N )
• tag ((new e : D) M ) = (new e : D)(tag, e:D
(M )). 

So tag (M ) systematically distributes the permissions in  to every agent in the

system M .
Theorem 5.44 (tagging preserves well-typing)   M if and only if   tag (M ).
Proof: By structural induction on M . For example suppose M is k
P . Then  
tag (M ) is equivalent to  k P, which in turn is equivalent to   k
P .

This result has an interesting corollary, which says that if the unannotated aDpi
system M is well-typed with respect to , then no runtime errors will occur in
the annotated version of M , where all agents are initialised with the permissions
described in :
Corollary 5.45 Suppose   M . Then Nt  −→err for every Nt such that
tag (M ) −→∗t Nt .
Proof: From the previous theorem we know   tag (M ) and the result therefore
follows immediately from type safety for tagged-aDpi, Proposition 5.42.

It is worth emphasising the import of this corollary. It means that there is no reason
to get involved in the complexities of tagged-aDpi, in which capabilities need to be
explicitly represented and managed at runtime. Instead of considering the tagged
system tag (M ) and its behaviour relative to the tagged reduction semantics, it
is sufficient to consider the untagged system M and its behaviour relative to the
simpler untagged reduction semantics. So long as   M we are assured that
tag (M ), running relative to the tagged reduction semantics, will never give rise
to a runtime error.
Example 5.46 Let us reconsider the aDpi system
Sysj ⇐ jane
codeJ | (new m : M)(m
LMem | c
C(m))
182 A distributed asynchronous pi-calculus

where the code for C(m) and codeJ is given in Example 5.37. And suppose j
is such that j jane xptp : rw Mp
, and it has sufficient capabilities to type the
memory correctly.
Then one can check that j  Sysj and consequently the explicitly annotated
system tagj (Sysj ) will never raise a runtime error relative to the tagged reduction
semantics; agents will only ever use resources for which they have explicit
permission.
However this is not the case for the system involving bob, Sysb in Example 5.36.
A corresponding type environment is some b , with respect to which the only
type that can be inferred for xptp at bob is rw Mp
. Here we have b   Sysb
and therefore the explicitly annotated system tagb (Sysb ) is not type-safe;
consequently there is a possibility of runtime errors. Indeed a runtime error does
occur, as detailed in Example 5.41. There the explicit permissions are slightly
different, but the same runtime error occurs in tagb (Sysb ); an agent emanating
from bob that tries to use the get method at m without permission.

Corollary 5.45 justifies the type system for aDpi in terms of the reduction
semantics of tagged-aDpi. But we can go even further by showing that this
reduction semantics of tagged-aDpi is essentially the same as that of aDpi. The
relationship is not completely straightforward, as reductions are not preserved under
the function tag ( ). That is M −→ N does not necessarily imply tag (M ) −→t
tag (N ), as the following very simple example shows.
Example 5.47 Let  be a type environment such that  k c : rw w
and let M
denote the system
k
c?(x) x! | (new a@k:rw) k
c! a

Note that   M . Then M −→ N , where N is (new a@k : rw)(k
a!) but
tag (M ) −→t tag (N ) . For tag (M ) decodes to the tagged system
k
c?(x) x! | (new a@k : rw)(k
c! a
 rw )
where  rw represents , a@k:rw. Note that the channel c can only transmit write
capabilities, and therefore the only tagged reduction from this, according to the rules
in Figure 5.13, is to a system structurally equivalent to (new a@k : rw) k
a! w
where  w represents , a@k:w.
But tag (N ), which decodes to (new a@k : rw) k
a! rw , cannot be structurally
equivalent to this system.

Of course this is not surprising as the tagged reduction semantics keeps a detailed
account of the distributions of permissions, which is not even represented in the
untagged systems. So to relate reductions in the two languages we need a more
subtle analysis.
 5.4 Type safety for aDpi 183

Definition 5.48 (tagging systems loosely) For each aDpi system M let Tag (M )
be the least (finite) set of tagged-aDpi systems that satisfies
• 0 ∈ Tag (0) whenever   env
• k
P ∈ Tag (k
P) if  <:  and  k P
• Mt | Nt ∈ Tag (M | N ) if Mt ∈ Tag (M ) and Nt ∈ Tag (N )
• (new e : D) Mt ∈ Tag ((new e : D) M ) if Mt ∈ Tag, e:D
(M ). 

Intuitively Tag (M ) returns the set of tagged systems structurally similar

to M , whose components have at most the permissions defined in .
For example, using the notation of Example 5.47 we have (new a@k : rw)
k
a! w ∈ Tag (N ); recall that k
a! w is the tagged system to which tag (M )
reduces.
The definition of Tag (M ) is really only designed with the case when   M
in mind, in which case we are guaranteed that it is non-empty; the first part of the
next result shows that it will always contain tag (M ).
Lemma 5.49
(i)   M if and only if tag (M ) ∈ Tag (M ).
(ii) Mt ∈ Tag (M ) implies   Mt .

Proof: The first statement is proved by induction on the structure of M . The two
base cases, when M is 0 or k
P  follow by definition, and the remaining two cases
follow trivially by induction.
The second statement also follows by a simple inductive argument on the
structure of M , the interesting case being when it has the form k
P . By definition
Mt must, in this case, take the form k
P  for some  such that  <:  and
 k P. But (weakening) immediately gives   Mt .

Theorem 5.50 Suppose Mt ∈ Tag (M ). Then

(i) M −→ N implies Mt −→t Nt for some Nt ∈ Tag (N )
(ii) Mt −→t Nt implies M −→ N for some N such that Nt ∈ Tag (N ).

Proof: The first statement is proved by induction on why M −→ N . We look at

some cases.
• Suppose it is an instance of the rule (r-comm),

k
c! V
 | k
c?(X ) R −→ k
R{|V/X |}

Here Mt must have the form

k
c! V
1 | k
c?(X ) R2

where 1 k c! V
, 2 k c?(X ) R, and  <: 1 ,  <: 2 . The typing of the input
agent ensures that r2 (c@k) exists. The typing of the output agent, and (weakening),
184 A distributed asynchronous pi-calculus

means  k V : w 1 (c@k), and the third part of Proposition 5.23 can be employed to
derive w1 (c @k) <:  (c@k). This is enough to ensure that V and  (c@k) match, and
r
2
r
2
therefore that V :2 (c@k)
@k is well-defined.
r

So we can apply the rule (rt -comm) of the reduction semantics for tagged-aDpi to get
Mt −→t k
R{|V/X |}2
where 2 is 2 , V :r2 (c@k)
@k.
We know by the previous lemma that   Mt , and therefore using subject reduction for
tagged-aDpi, Theorem 5.40, we have
  k
R{|V/X |}2

However this typing judgement is enough to ensure that k
R{|V/X |}2 ∈

Tag (k
R{|V/X |}).
• Suppose the reduction is an instance of (r-c.create):

k
(newc c : C) P −→ (new c@k : C) k
P

Here Mt must take the form
k
(newc c : C) P
where  <:  and  k (newc c : C) P.
The reduction semantics for tagged-aDpi gives
Mt −→t (new c@k:C) k
P
where  denotes , c@k:C. Again the typing judgement is sufficient to ensure the
inclusion of (new c@k:C) k
P in Tag ((new c@k : C) k
P).

The remaining axioms are similar, and all of the rules, apart from (r-str), follow
by induction. For (r-str) we need to establish the relationship between structural
equivalence and Tag ( ). See Question 11 at the end of this chapter.
The second statement is proved in a similar manner, by induction on the inference
of Mt −→t Nt , and an analysis of why Mt is in Tag (M ). The details are left to
the reader. The only non-trivial case is when the tagged reduction is an instance of
(rt -comm), where subject reduction for tagged-aDpi is used.

The next, and final, result emphasises the import of this theorem. It shows that the
computations in the untagged language from system M , well-typed with respect to
, are essentially the same as the tagged computations from tag (M ).
Corollary 5.51 Suppose   M . Then M −→∗ N if and only if tag (M ) −→∗t Nt
for some Nt ∈ Tag (N ).
Proof: Since   M we know tag (M ) ∈ Tag (M ). Therefore the result follows
by repeated application of the previous theorem.

 5.5 Distributed consistency of local channels 185

To summarise this section, we have shown that the resource access types for
aDpi developed in Section 5.2.1 enforce an implicit regime of access permissions
to resources. Specifically an aDpi system M , well-typed with respect to , may
be taken to represent the explicitly annotated system Tag (M ). Because it is well-
typed we are assured that Tag (M ), when run relative to the reduction semantics
in which permissions are explicitly manipulated and managed, will never misuse
these permissions. Moreover this runtime behaviour, with explicit management
of permissions, is adequately modelled in the reduction semantics of aDpi, when
restricted to well-typed systems.

5.5 Distributed consistency of local channels

In aDpi channel or resource names have only local significance, in that such a
name is only useful if the owner also knows its location; thus the importance of
located names, such as c@l and c@k. In this framework the same name can be used
at different locations, for what are essentially independent resources. For example
consider the system s
P  where P is the code
(newloc s1 : S1 ) with P1 in
(5.43)
(newloc s2 : S2 ) with P2 in xpt1 ! print @s1
| xpt2 ! print @s2

where the location types Si contain the local resource name print. This sets up
two new sites s1 , s2 , which are locally serviced by the code P1 , P2 respectively,
and the print, created at each site, is exported along the distribution channels xpti ;
the actual values exported are located, consisting of the name print together with
where it is defined. A user or client, with access to both export channels, xpt1 and
xpt2 will gain knowledge of the existence of the resource print at these two distinct
locations, via the located names print @s1 and print @s2 respectively.
However despite sharing the same name, a priori, there is no reason for these
two local resources to have anything in common. In this instance their types are
determined by the type associated with the newly created locations. These, for
example, could be given by
S1 = loc[print : rw str
, . . .]
S2 = loc[print : (int, r w bool

), . . .]
Then at location s1 , print is a resource for handling strings, while at s2 print expects
pairs, the first of which should be an integer, and the second a local channel, with
some specific capabilities. Although our type system will correctly manage the
disparity between the two instances of the resource name print, it puts considerable
strain on any user of these resources, since they have to continually remember
which occurrence of print is being used.
186 A distributed asynchronous pi-calculus

But the type system can be modified so as to ensure consistency between multiple
instances of the same local resource name. There are various approaches, depending
on the level of consistency one wishes to enforce, and in the remainder of this chapter
we outline one possibility. The general idea is to introduce a new form of global
declaration, for registered resource names, and to insist that when new locations
are generated they can only use resource names that have already been registered;
moreover the types at which the locations use these names must be consistent with
the types at which they have been registered. There are various possibilities for
what is meant by consistent here. We outline a simple example, demanding that
the type of a resource at each location must be a supertype of the type at which it
has been registered. With such an approach there will be no type environment 
for which
  s
P 
where P is given by (5.43) above. For the resource name print must be registered
in  at some type, say Tp ; this we will denote as an entry print : rc Tp
in , and
well-typing will impose the two constraints
Tp <: rw str
Tp <: (int, r w bool

)
which are unsatisfiable; these two types have no lower bound.
We now outline the changes necessary to implement this scheme as part of
the typing system; for clarity let us use rc in place of  when discussing the extra
requirements. First we must adapt the formation rules for well-formed environments
to allow the new kind of entries, of the form n : rc C
, indicating that n is a globally
defined registered resource name. The details are outlined in Figure 5.15. The new
rule (e-rc) allows new registered names to be added to environments at a so-called
registration type rc C
; note that for simplicity we will only allow names, and not
variables, to be registered.
The effect of the presence of registered names is felt in the new rules for adding
information about a local channel u, which replace the general rule (e-chan) in
Figure 5.9. The first, (e-chan.rc), applies when u already appears in  as a globally
defined registered name; in this case the newly added capability, at any site w, must
be supported by the registration type. The second rule, (e-chan.nrc), is essentially
the same as the old rule; when u is not registered the added capability must be
consistent with all existing capabilities on u at the site in question; the notation
 rc u : rc just means that there is no entry of the form u : rc C
in . Note that
these rules rely on value typing judgements; these remain unchanged, inheriting
the judgements from Figure 5.9.
However the most significant modification is to the subtyping rules in Figure 5.7,
which also implicitly dictate the rules for constructing well-formed types. Now the
 5.5 Distributed consistency of local channels 187

Figure 5.15 Types for registered resource names

judgements must take the form

 
rc
T1 <: T2
in which subtyping, and therefore type construction, is relative to a well-formed
type environment. The only place in which the presence of  has an effect is in
constructing location types, (sub-loc). To deduce
 
rc
loc[a1 : C1 , . . . , an : Cn ] <: loc[a1 : C1 , . . . , an : Cn ]
that is to construct the type loc[a1 : C1 , . . . , an : Cn ], each ai has to be registered
in  as a resource name; moreover the proposed type of ai must be consistent with
its registered type.
As in Definition 5.8, these subtyping rules determine when types are well-formed;
we write  rc T : ty to mean that we can derive the judgement  rc T <: T. Here
the only real role for  is to ensure that if T is a location type, or uses a location type,
then all resource names in that type are registered in . Adapting Definition 5.8,
we let Types denote the set of all types T for which we can derive  rc T : ty.
188 A distributed asynchronous pi-calculus

Proposition 5.52 For every valid type environment , the pre-order Types , <:

is partially complete.
Proof: The proof is virtually identical to that of Proposition 5.9, despite the presence
of the extra parameter .

The requirement to establish the validity of a type expression relative to a type

environment really only has an impact for location types. The rule (sub-loc) from
Figure 5.15 can be specialised to
(ty-l.type)
 rc ai : rc Ci
, 0 ≤ i ≤ n (5.44)
  rc
loc[a1 : C1 , . . . , an : Cn ] : ty
Indeed it is easy to see that if  rc loc[a1 : C1 , . . . , an : Cn ] : ty then it can be
established by an instance of this rule.
Note that in this modified typing framework the rules for environment
construction, subtyping, and value typing are all mutually dependent. This may
seem somewhat complex, but nevertheless rule induction can still be used to
establish the various required properties of all these judgements. One significant
new property emphasises the role of registered names:
Proposition 5.53 Suppose  rc n : rc. Then  rc
w n : C implies  rc n : rc C
.
Proof: By induction on the proof of  rcw n : C. The only non-trivial case is the
base case, when this is inferred from (ty-c.sub) in Figure 5.9. Here  has the form
1 , n@w : C , 2 where C <: C. The (sanity checks) on environment formation
give that
1 , n@w : C 
rc
env (5.45)
and moreover since registered name declarations are unique we must have that
1 rc n : rc. So (5.45) can only be inferred using the rule (e-chan.rc) from
Figure 5.8, which means that 1 rc u : rc C
. The required  rc n : rc C
follows
by (subsumption) and (weakening), which can be established for the extended
typechecking system.

This new notion of type environment can now be used in typing judgements for
systems and processes. The rules in Figures 5.10 and 5.11 can remain virtually
unchanged. But we need to modify the manner in which new location declarations
are handled; see Figure 5.16. For example to ensure that (new k : K) M typechecks
relative to  we need to check that M typechecks relative to the augmented
environment , k:K
as before, but also that K is a well-formed location type,
that is  rc K : ty; this ensures that all the resource names used in K have already
been registered.
 5.5 Distributed consistency of local channels 189

Figure 5.16 Typing with registered resource names

However we also need to revise our rules for typing the match construct if v1 =
v2 then R1 else R2 . Recall that for aDpi the rule (ty-mis.match) in Figure 5.11 is
necessary in order to cover the possibility that the augmented environment used in
the premise of (ty-match), , v1 :A2
@w, v2 :A1
@w w R1 , is not well-defined.
In aDpi if  is a well-defined environment, then so is , v1 :A2
@w, v2 :A1
@w,
unless A1 ↓ A2 . However in the presence of registered names it turns out that there
are more reasons for this augmented environment to be ill-defined, not covered
by the rule (ty-mis.match). To cover all possibilities we therefore use the rule
(ty-mis.match.gen), which simply says that when the augmented environment
is not well-defined it is sufficient to type R2 in the original environment. We are
guaranteed that if , v1 :A2
@w, v2 :A1
@w, is not a well-defined environment, then
v1 and v2 must be different and therefore only the else branch will ever actually be
executed. See Question 17 at the end of this chapter for an alternative approach to
typing the match construct.
This new typechecking framework enforces a primitive form of consistency
between independent systems that use the same name for independent local
resources. A typical example occurs in the typing of the memory servers from
Example 5.7, discussed in Example 5.18.
190 A distributed asynchronous pi-calculus

Example 5.54 (Located Memory Servers, Again) Let us reconsider the system
s
LmemS | c1
Client1  | c2
Client2 
from Example 5.7, where the server at s generates memory cells at type M and
clients generate reply channels at type R to be sent to the server. A priori these clients
are completely independent from the server, but there is an implicit dependency
between them, in the requirements on these types. Both use the resource names
put, get and there is an agreement in principle that they are each declared locally
at the same types, Tp and Tg respectively.
First let us see that the type judgement for this example system, given in
Example 5.18, no longer works in the presence of resource registration types. Let
us assume req has as an entry req : rw w M
@loc
, in addition to whatever is
required to type the clients; moreover since req is inherited from the previous
section we also assume it contains no registered resources names. Typechecking
now breaks down when we try to establish
req 
rc
s
LmemS
that requires the judgement
req rc
s (new m : M)(LmemS | . . .)
The only possible rule to apply here is the revised (ty-lp.new), which now requires
the premise
req rc M : ty (5.46)
Recall from (5.30) on page 156 that M is the type loc[put : rw Tp
, get : rw Tg
],
and so establishing (5.46) via the derived rule (ty-l.type) in (5.44) above would
require  rc put : rc Tp
. But this is not possible, as neither of the resources put
and get are registered in req .
However let pg be a type environment with the entries
put : rc Tp
, get : rc Tg
, req : req : rw w M
@loc

Then any system defined relative to this type environment is working under clear
assumptions about the purpose of the two names put and get; they must be used at
all locations in a manner consistent with their registered types. This refers to clients
generating reply channels at types that use these names, but more importantly to
the server when it wishes to generate new domains that offer resources with these
names.
Indeed it is now easy to see that the derivation of the original type judgement
can easily be adapted to obtain
pg 
rc
s
LmemS | c1
Client1  | c2
Client2 
 5.6 Questions 191

Here we can derive the required judgement pg rc M : ty using (ty-l.type)
because put and get have been declared as registered resources in pg . But equally
important is the fact that any other client, who wishes to use the resource names
put and get, for example in new location declarations, is obliged to use them at a
type consistent with their registration type in pg .

The standard properties of typechecking systems developed in Section 5.3 can

also be shown to hold for this framework with registered resources. However
we need to be careful about the manner in which envionments are compared,
generalising Definition 5.24 to: WW

Definition 5.55 (comparing environments with registered resources) For valid type
environments, we write 1 <: 2 if for every identifier w,
(i) 2 rc
w u : A implies 1 w u : A
(ii) 1 rc
w u : rc C
if and only if 1 rc
w u : rc C
. 

In other words we do not allow any subtyping with respect to the types at which
resources are declared; 1 <: 2 only if both environments have exactly the same
registered resources, with exactly the same declaration types.
With this generalisation the properties such as (weakening), (strengthening), etc.,
from Section 5.3 still hold. We leave their proofs to the reader, and simply state the
most important one:

Theorem 5.56 (subject reduction with registered resources) Suppose  rc M and
M −→ N . Then  rc N .

5.6 Questions
1. Prove that (new e : D) M ≡ M whenever the bound names in e does not occur free
in M .
2. • Show that the subtyping relation over the set Types, as given in Definition 5.8, is a
partial order.
• Prove that Types, <:
is partially complete; that is fill in the details to the proof of
Proposition 5.9.
3. Consider the following server for generating distributed forwarders, based on
Example 5.3: s
DisFServ where the code DisFServ is given by

DisFServ ⇐ rec z. req?(x1 @y1 , x2 @y2 , x@y) (z | y.x! | DisF(y1 , x1 , y2 , x2 ))

where DisF(y1 , x1 , y2 , x2 ) is obtained from DisF(k1 , b, k2 , c) in the obvious manner.

Give a type environment, containing only an entry for req@s, with respect to which the
server is well-typed.
192 A distributed asynchronous pi-calculus

4. Consider the searching process defined by:

Search ⇐rec z. test?(x) if good(x) then goto h.report! x

else
neigh?(y) goto y.z

When run at a specific domain, it reads some data from the channel test, and runs a
check on it, with the predicate good. If the check passes it reports to some home base
h. Otherwise it uses the channel neigh to find a neighbour of the current location, and
starts the searching process all over again from there.
Show that it is not possible to type the system k
Search, for any location k.
How could the typing system be extended so that k
Search could be properly typed?
5. This is a generalisation of Question 2 from Chapter 4 to aDpi. Suppose 1 , 2 are two
valid type environments with 1 <: 2 . Prove
(i) 1 , ẽ:D̃
 env implies 2 , ẽ:D̃
 env.
Note that here there is no assumption about identifiers in (ẽ) being fresh.
(ii) If bn(ẽ) are fresh to 1 then 2 , ẽ:D̃
 env implies 1 , ẽ:D̃
 env.
(iii) 1 w V : T implies 2 , V :T
@w  env.
(iv) 1 <: 2 , V :T
@w.
Show that these four results also hold for type environments with registered resources,
from Section 5.5.
6. Let us say that e1 , e2 interchange, if one of the following conditions hold:
• both e1 , e2 are located identifiers
• both are simple names
• e1 is a simple name that does not occur in e2 .

Suppose 1 , e1 : A1 , e2 : A2  env, where e1 and e2 interchange. Prove that 1 , e2 :

A2 , e1 : A1 is also a valid type environment.
7. Suppose  is a closed environment, that is contains no variables, such that   k : loc.
Show that there is an environment   not containing k and a location type K such that
 ≡   , k:K
.
Is this true when  rc k : loc?; that is when the type environment can contain registered
resources?
8. Again suppose   env is a closed environment. Prove that there exists a sequence
of names k1 , . . . , kn , and location types K1 , . . . , Kn , for some n ≥ 0, such that  ≡
k1 :K1
, . . . , kn :Kn
.
9. An environment  is in standard form if there is at most one entry for every compound
value e in .
(i) Prove that for every well-defined environment,  rc ty, there is one in standard
form   such that  ≡   .
(ii) Suppose  is in standard form and  w V : T. Show that there is a derivation of
this judgement that does not use the rule (ty-meet).
 5.6 Questions 193

10. Here we generalise Question 11 of Chapter 3 Let σ be a mapping over Names ∪ Vars
that maps names to names and variables to variables. Let σ be the type association
list obtained from  by
• replacing every occurrence of u : E with σ (u) : (Eσ )
• replacing every occurrence of u@w : C with σ (u)@σ (w) : (Cσ ).
Note that channel types and registered name types can contain names; thus (E)σ is the
result of substituting every occurrence of n by σ (n) in E. Assuming σ is injective on
the set of (simple) identifiers that occur in , prove:
(i)   M implies σ  M σ
(ii)  rc M implies σ rc M σ .
11. Suppose M ≡ N . Prove that Mt ∈ Tag (M ) implies there exists some Nt ∈ Tag (N )
such that Mt ≡ Nt .
12. Show that subject reduction still holds in the typing system of Figure 5.10, if
(ty-mis.match) in Figure 5.11 is replaced by (ty-mis.match.gen) from Figure 5.16.
13. Consider the type system with registered names from Section 5.5. A type environment
is called reduced if  rcw1 n : C1 and  rcw2 n : C2 implies w1 = w2 , whenever
 rc n : rc. In other words local channel names exist at a unique site unless they have
been declared as a registered resource.
Suppose  rc M , where  is reduced. Then show that  rc M can be inferred using
judgements that only contain reduced environments.
14. Prove Theorem 5.56, subject reduction for the typing system with registered resource
names.
15. Show that the substitution result Proposition 5.31 no longer holds in the presence of
registered resources if (ty-mis.match.gen) is replaced by (ty-mis.match).
16. Use the previous question to show that subject reduction also does not hold
in the presence of registered resources, if (ty-mis.match.gen) is replaced by
(ty-mis.match).
17. Prove that subject reduction will hold for the system with registered resource names if
(ty-mis.match.gen) is replaced by (ty-mis.match) together with the following two
rules:
(ty-mis.match.r1 )
 w v1 : A1
 dec v2 : rc A2

 w R2 : proc
A2  <: A1
 w if v1 = v2 then R1 else R2 : proc
(ty-mis.match.r2 )
 w v2 : A2
 dec v1 : rc A1

 w R2 : proc
A1  <: A2
 w if v1 = v2 then R1 else R2 : proc
Here the notation  dec v : rc A
means that the type association v : rc A
occurs in .
 6
Behavioural equivalences for aDpi

In this chapter we apply the theory developed for aPi in Chapter 4 to aDpi. For
technical reasons it is best to work relative to the extended typing system developed
in Section 5.5, although to avoid unnecessary clutter we will abbreviate rc to
simply  .
The motivation for this theory, the relativisation of behavioural equivalences to
the partial knowledge of observers as explained in Chapter 4, applies equally well, if
not more so, in a distributed setting. Consequently it is not repeated here. Moreover
the technical framework, developed in detail in Chapter 4, is easily adapted to
aDpi. So we simply apply it, modifying the various concepts as necessary to the
distributed setting, in what we hope is a natural manner.
In the first section we discuss distributed actions-in-context and the associated
typed bisimulation equivalence, ≈bis , for aDpi systems. Most proofs of the expected
properties of this equivalence are left to the reader as they can be easily constructed
from the corresponding ones in Sections 4.1 and 4.2.
This is followed by a section on examples, which demonstrates that at least
in principle standard bisimulation-based proof methodologies can be adapted to
our setting. Necessarily there are more syntactic details to contend with; but in
time appropriate software tools, based for example on theorem provers, could be
developed to partially alleviate the tedium.
In the final section we revisit the subject first broached in the untyped setting of
aPi, in Section 2.5, namely the justification of our typed bisimulation equivalence
for aDpi. This involves developing a typed version of the touchstone equivalence
=
∼ and applying it to the distributed setting of aDpi. We show that bisimulation
equivalence ≈bis is sound with respect to =, ∼ thus establishing that bisimulations
provide an adequate technique for establishing behavioural identities. Of course
readers still familiar with the contents of Section 2.5 will realise that the converse
is not true; Example 2.29 is readily adapted to aDpi. So there are distributed
systems that cannot be reasonably distinguished, but that can never be related

194
 6.1 Actions-in-context for aDpi 195

using a bisimulation. The attentive reader will also know the remedy. We develop
an asynchronous version of bisimulation for aDpi, and adapt the technique of
Section 2.7 to show that this asynchronous version of bisimulation equivalence
is complete relative to =;
∼ if two aDpi configurations are related via =
∼ then there
exists some (typed) asynchronous bisimulation that relates them.

6.1 Actions-in-context for ADPI

As in Chapter 4 we consider configurations, this time consisting of aDpi
systems, coupled with partial knowledge of their resources encapsulated in a type
environment.
Definition 6.1 (configurations in aDpi) A configuration is a pair
I M
where M is a system from aDpi such that   M for some type environment
 compatible with I , that is  <: I . It is assumed that both I and  are valid
environments; moreover since M is a closed term, that is it contains no free
variables, we may assume that the domain of I , and also that of the implicit ,
only contains names, and located names. 
We define (distributed) actions-in-context
µ
I  M −→ I  M  (6.1)
representing the ability of M to interact with its environment, together with the
ability of the environment, with knowledge I , to participate in the interaction. As in
aPi the only forms of possible interaction are input or output along a communication
channel; but now these channels, or resources, are located. Consequently the
possible typed action labels µ are as follows:
αi = (ẽ : D̃)k.a?V : the input of value V along the channel a, located at the site k; the
bound names in the set (ẽ) are freshly generated by the environment.
αo = (ẽ : D̃)k.a!V : the output of value V along the channel a, located at the site k; here
the bound names in (ẽ) are freshly generated by the system.
τ : this represents, as usual, some internal activity.

We extend the complementary notation for action labels, µ, used for aPi, in the
obvious manner; τ is τ itself; if αo is (ẽ : D̃)k.a!V then αo is the corresponding
input label (ẽ : D̃)k.a?V , while αi is the output label (ẽ : D̃)k.a!V , if αi is the
output (ẽ : D̃)k.a!V .
As usual the standard assumptions on bound variables in these actions (6.1) are
in force. Thus all bound names are assumed to be fresh, relative to the environment
I and system M , although for emphasis this requirement is sometimes explicitly
mentioned. We also employ the same consistency requirements on these µ as in
196 Behavioural equivalences for aDpi

Section 4.1, adapted to take into account possible compound names. So for example
for (e : D)α to be well-formed we require α to be well-formed, and the bound name
in e to
• be different from the location and channel used in α
• be different from the bound names in α
• appear somewhere in α.

The occurrence of these actions-in-context depends on the environment having

appropriate capabilities on located channels. To describe these we use the notation
referred to after Definition 3.25, on page 87, to describe the read/write capabilities
associated with a given channel in a type environment, relative to a given location;
for example I r (a@k) gives the read capability, known to I , on the channel a at the
location k.
The actions-in-context (6.1) are defined to be the least relations over
configurations satisfying the axioms and rules in Figures 6.1 and 6.2. These are
simply a localised adaptation of the corresponding axioms and rules for typed aPi
in Figures 4.1 and 4.2; each possible action may occur at a specific location, say
k, and the various requirements for the action-in-context to be defined are checked
locally, at this k. Input is governed by two rules, (l-in) for values that are already
known to the environment, and therefore the system being observed, and (l-weak)
for names newly invented by the observer; in the latter we use the general notation
e:D
developed after Definition 5.12, for extracting type association lists from
system level name creations. The (implicit) requirement in this rule that I , e:D

is a well-defined environment, is crucial to the proper management of new names.

For example consider the judgement
αi
I  k
a?(X ) R −→ I  N

Let us look at three instances of the input action label αi .

• αi is (b@l : C)k.a?b@l: here, in order for I, e:D
, that is I, b@l : C, to be well-defined, it
is necessary for l to be already known as a location in I, that is I  l : loc. So the label
represents the transmission at location k, from the observer to the observed system, of
the name of a new resource b, with type C, at a location already known to both observer
and observed, namely l.
• If αi is (l : loc, b@l : C)k.a?b@l then the label represents the transmission, again at k, of
a new resource b at the newly created location l.
• If it is (l : loc[in : I])k.a?l then it represents the transmission of a new location l, which
has been created at type loc[in : I]; here the receiving agent, in addition to being able to
use the newly acquired location name l, may also use the located name in@l, of a non-local
resource at type I. Because we are using aDpi with distributed consistency of resource
names this channel in must be a registered resource.
 6.1 Actions-in-context for aDpi 197

Figure 6.1 External actions-in-context for aDpi

Finally note that although the moves are decorated only with new global
information, (ẽ : D̃), new local information can also be generated. For example
when αi is (b@k : C)k.a?b the label represents the transmission of a newly created
local channel b, created at the site local to the action, namely k.
Output is also governed by two rules, (l-out) for the transmission of values
that intuitively are assumed to be known to the observer, and (l-open) for the
transmission of newly created names, this time newly created by the system
being observed. Note that, as with typed aPi, there is an important implicit side-
condition here, namely that the resulting label is well-defined. Thus to apply this
rule the bound name in e must appear somewhere in the label αo , although it is
also required to be different from all the existing bound names there. Also as in
typed aPi the observer receives values at the transmission type of channel a at
k, rather than at the declaration type; the example discussed on page 102 is easily
198 Behavioural equivalences for aDpi

Figure 6.2 Internal actions-in-context for aDpi

generalised to the distributed case. Again as in typed aPi, in (l-out) the fact that
I  k
a! V
 is a configuration ensures that the augmented association list, namely
I , V :I r (a@k)
@k, is always a well-defined type environment; see Question 3 at
the end of the chapter. The final rule in Figure 4.1 (l-ctxt) is a standard contextual
rule; but note that the side-condition in the second clause, bn(e)  ∈ µ has extra
significance here as bn(e) may in principle occur in the types used in µ.
Most of the rules governing internal actions-in-context are taken directly from
the reduction semantics; the only exception, (l-comm), is adapted from typed
aPi. The internal communication does not change the external knowledge I , and
is independent of the actual environments I1 and I2 necessary to provoke the
constituent actions.
In Chapter 4 we went into considerable detail developing the properties of
actions-in-context for aPi. Here we spare the reader many of the detailed proofs;
instead we will simply state their properties, leaving it to the reader to check that the
proofs given there can be adapted to aDpi. But we do need to develop the notation
required to state these properties.
Notation 6.2 We first define the effect of actions on environments, generalising
Definition 4.6. Let the partial function after be defined by
• (I after τ ) is I.
• If µ is the input label (ẽ : D̃)k.a?V then (I after µ) is defined to be I, ẽ:D̃
; recall that
here we know that all the bound names in (ẽ) are fresh to I.
• If µ is the output label (ẽ : D̃)k.a!V then (I after µ) is defined to be I, V :I r (a@k)
@k.

Of course in each case the result is only defined if it is a valid environment.

 6.1 Actions-in-context for aDpi 199

Next let us define another partial predicate allows, which determines when an
action is possible in an environment.

• I allows τ is always true.

• I allows (ẽ : D̃)k.a?V is true whenever I w (a@k) is defined and I, ẽ:D̃
k V : I w (a@k).
• I allows (ẽ : D̃)k.a!V is true whenever I r (a@k) is defined.

µ
Finally we write, mimicking Notation 4.8, M −→ N to mean that there exist some
 µ 
environments I , I , such that I  M −→ I  N ; this means that M can in principle
perform the action µ.

Note that as with typed aPi, the definitions of (I after µ) and (I allows µ)
are independent of the types in µ, whenever it is an output label. Specifically let
µ ∼ µ mean that un(µ) = un(µ ), where un( ) is the obvious generalisation of
the function given in Section 4.2.1, which eliminates the types from output labels,
and leaves others untouched. Then

• (I after µ) = (I after µ )
• (I allows µ) if and only if (I allows µ ).

Let us now simply enumerate the important properties of actions-in-context for

aDpi, expected in the light of Section 4.1.
µ
1. (Determinacy on environments) If I  M −→ I   N then (I after µ) is well-defined

and coincides with I . (See Proposition 4.7.)
µ
In view of this result we abbreviate actions-in-context to the form I  M −→ N.

µ µ
2. (Allowing actions) If I allows µ and M −→ N then I  M −→ N , for any configuration
I  M . (Again see Proposition 4.10.)
Intuitively this means that if M is capable of performing an action, and I allows it, then
the action can be performed by the configuration I  M .

µ
3. (Subject reduction) If I  M −→ N and   M then
• if µ is τ then   N
• if µ is the output action (ẽ : D̃)k.a!V then  w (a@k)↓def , ( after µ) k V :  w (a@k)
and ( after µ)  N
• if µ is the input action (ẽ : D̃)k.a?V then  r (a@k)↓def , and ( after µ)  env implies
( after µ)  N .
(See Theorem 4.12.)
As in the previous chapter the proof here depends on the fact that I  M is a
configuration.

µ
4. (Configurations) If I  M is a configuration and I  M −→ N then (I after µ)  N is
also a configuration. (See Corollary 4.13.)
The proof, as with typed aPi, relies on subject reduction.

200 Behavioural equivalences for aDpi
µ µ
5. (Structural equivalence) Suppose M ≡ N . Then I  M −→ M  implies I  N −→ N
  
for some N such that M ≡ N . (See Proposition 4.14.)

6. (Reduction semantics) Suppose I  M is a configuration. Then M −→ M  if and only
τ
if I  M −→ M  for some M  such that M  ≡ M  . (See Corollary 4.17.)
The proof involves describing the precise structure of external actions, as in
Proposition 4.16.

6.2 Typed bisimulation equivalence for aDpi

We now have in place the necessary machinery to define a bisimulation equivalence
for aDpi, mimicking Definition 4.20. We have the following lts:
• The states consist of all aDpi configurations (I  M ).
• The action labels consist of:

– input: (ẽ : D̃)k.a?V

– output: (ẽ)k.a!V
– internal: τ
where the standard consistency requirements on the bound names are enforced.
• The next state relations are given by:

– the judgements
µ
(I  M ) −→ (I after µ  N )

that are derivable from the rules in Figures 6.1 and 6.2, when µ is an input action or
the internal action τ ;
– the judgements
(ẽ:Ẽ)k.a!V
(I  M ) −
−−−−−→ (I after µ  N )

for some collection of types (Ẽ), when µ is the output action (ẽ)k.a!V .

The reason for abstracting away from the types in output moves is explained in detail
in Example 4.18 for aPi but it applies equally well to aDpi. Essentially observers
are oblivious to the declaration types of newly acquired resource names, and simply
receive them at the capabilities determined by the output type of the channel through
which they are transmitted. We also extend the equivalence between action labels
for aPi, given on page 113, in the obvious manner. If µ and µ are output labels
then µ ∼ µ means that their untyped versions are the same; otherwise µ and µ
must be identical.
Consequently we can apply the standard definition, to obtain a bisimulation
equivalence between aDpi configurations. As usual we are principally interested in
comparing systems under the same external assumptions and consequently we use
 6.2 Typed bisimulation equivalence for aDpi 201

the same notation as in Chapter 4:

I |= M ≈bis N
means that the configurations (I  M ) and (I  N ) are bisimilar. Indeed we can
also adapt the terminology developed there and specify bisimulations for aDpi by
defining a parameterised family of relations R, with the property that M , N
∈ RI
implies that both I  M and I  N are configurations; moreover this will often be
written as I |= M R N . The required transfer property then amounts to demanding
that every action-in-context
µ
(I  M ) −→ M
has a matching one


(I  N ) =µ⇒ N 
such that
(I after µ) |= M  R N 
and µ ∼ µ ; recall from page 113 that this relation between action labels simply
abstracts away from the types of extruded names in output actions. If the relations
RI are not symmetric we will also require the corresponding transfer property for
actions-in-context from (I  N ).
In Section 4.2 we expended considerable effort in developing non-trivial
properties of this relation for aPi. Here we simply enumerate the more interesting
ones: we omit the proofs as these follow the same lines as those elaborated for aPi.

(A) (Strengthening) Let I <: Il . Then I |= M ≈bis N implies Il |= M ≈bis N .

(See Proposition 4.22.) Note however that the proof requires some properties of actions-
in-context for aDpi, which we have not enumerated in the previous section. See
Questions 4 and 5 at the end of the chapter.

(B) (Fresh weakening) Suppose I, e:E
is a valid environment, where bn(e) do not appear
in I. Then I |= M ≈bis N implies I, e:E
|= M ≈bis N .
(See Proposition 4.23.)

(C) (Compositionality) Let I  O. Then I |= M ≈bis N implies I |= O | M ≈bis O | N .
(See Proposition 4.24.) As we have seen the proof of this result for aPi requires the
definition of a rather complicated typed relation between configurations. However
exactly the same proof will apply to aDpi, although establishing that the adapted
relation is indeed a bisimulation is somewhat more tedious, because the formation of
valid type environments for aDpi is more subtle.

However rather than spend more effort on repeating these proofs let us consider how
we may adapt standard techniques to demonstrate the parameterised equivalence
between systems.
202 Behavioural equivalences for aDpi

6.3 Describing bisimulations

To show that two systems M and N are equivalent relative to a configuration I
it is sufficient to exhibit a relation R that contains the pair I  M , I  N
and
that satisfies the requirements of being a bisimulation. In fact as we have already
stated, witness bisimulations are often more conveniently presented as a family of
relations R parameterised on type environments. However even for very simple
systems describing bisimulations in any form can be quite onerous, as the required
relations can be difficult to describe precisely.
There are numerous ways of alleviating this burden, some of which we examine
here. One method is to develop algebraic laws that are satisfied by semantically
equivalent systems. Structural equivalence gives one simple set of such laws.
Corollary 6.3 Suppose M ≡ N . Then I |= M ≈bis N .
Proof: An immediate consequence of Proposition 4.14, which has been generalised
to aDpi in (5) on page 200.

What this means is that axioms for structural equivalence in Figure 5.4 can be used
as equational laws for manipulating system descriptions. So for example we now
know
(new e : D)(M | N ) ≈bis M | (new e : D) N whenever bn(e)  ∈ fn(M )
We will later see more such laws.
Another approach to alleviating the burden of exhibiting witness bisimulations
is to extract structure common from the system descriptions. (Compositionality),
item (C) above, justifies one such instance, where the common structure involves
a concurrent system. Another instance is justified by the following result.
Proposition 6.4 (scoping) Suppose that both I  (new e : D) M and I 
(new e : D) N are configurations. Then I |= M ≈bis N implies I |=
(new e : D) M ≈bis (new e : D) N .
Proof: Note that our ongoing implicit assumptions about the freshness of bound
names, ensures that in this statement we know that the bound name in e does not
appear in I .
Let R be the family of relations defined as follows: I |= M R N if
(i) I |= M ≈bis N
(ii) or M , N have the form (new e : D) M1 , (new e : D) N1 respectively, where I |=
M1 ≈bis N1 .

The result will follow if we show that R is a bisimulation. So suppose I |= M R N

µ µ
and I  M −→ M  . We have to find a matching action-in-context I  N =
⇒ N
such that (I after µ) |= M R M  and µ ∼ µ .
 6.3 Describing bisimulations 203

The non-trivial case is (ii), when M , N have the form (new e : D) M1 ,

(new e : D) N1 respectively, where we have to examine the inference of the action-
in-context; in particular the last rule used in the inference. There are only two
possibilities; we examine one, when it is (l-open). So µ has the form (e : D)αo for
some output label αo , and I  M1 −α→ o
M1 .
Since I |= M1 ≈bis N1 , this move can be matched by an action-in-context I 
αo
N1 =
⇒ N1 such that αo ∼ αo and I after αo |= M1 ≈bis N1 . Now (l-open) can also
µ
be applied to this move, to obtain I  (new e : D) N1 =

⇒ N1 where µ is (e : D)αo .
This is the required matching move, since I after αo coincides with I after µ.

Another convenient technique allows us to use witness bisimulations in which

moves need only be matched approximately. For example in the untyped setting
Proposition 2.19 means that the matching need only be carried out relative to
structural equivalence; in effect in a bisimulation up to structural equivalence each
occurrence of a process actually represents all processes structurally equivalent
to it. This result can easily be generalised to aDpi, under the convention, which
we will apply in this section, that structural equivalence applies to configurations.
However here we will generalise the result further, allowing us to abstract away
from many of the housekeeping moves in the operational semantics of aDpi.
Consider the rules for internal actions-in-context given in Figure 6.2. It turns
out that all of these, except (l-comm), give rise to moves whose occurrence does
not really affect the subsequent behaviour of systems. To see this let us revise the
operational semantics by labelling all internal moves, other than communications,
with τβ replacing the label τ used on the internal moves inferred from all the
axioms with the annotated label τβ . In other words the axioms (l-eq), (l-neq), …,
(l-l.create) and (l-c.create) in Figure 6.2 now all give rise to instances of

I  M −τ→
β
N

so-called β-moves. So for example we have

I  (new r @k : R)(k
r?(x) Q | k
goto l.in! r

)
−τ→
β
(new r @k : R)(k
r?(x) Q | l
in! r
)
I  k
if a = b then P else (newc c : C) (Q1 | Q2 )
−τ→
β ∗
(new c@k : C)(k
Q1  | k
Q2 )
τ
In the sequel we will continue to use (I  M ) −→ N to refer to any internal
move, annotated or not. We will also use the notation M −τ→ β
N for the fact that
τβ τ τβ
(I  M ) −→ N , for some I . Thus, as with −→, we will use −→ interchangeably as a
relation over systems, or over configurations; it will also be convenient to consider
204 Behavioural equivalences for aDpi

structural equivalence as a relation over configurations, by letting (I  M ) ≡

(I   N ) if I coincides with I  and M ≡ N . We leave the reader to check that the
following two properties, which we have already established for τ , specialise to
the annotated version:

Lemma 6.5
τ τ
• M −
→β
N implies I  M −
→β
N for every configuration I  M .
τβ τβ
• M ≡ N and I  M − → M  implies I  N −→ N  for some N  such that M  ≡ N  .

The main technical property of β-moves is given in the following lemma. Here,
and often in the sequel, for the sake of clarity we revert to the original notation for
describing actions-in-context, as relations over configurations.
τβ
Lemma 6.6 (β-commutativity) Suppose I  M −
→ I  M  . Then for every other
µ
move I  M −→ (I after µ)  N either
(i) µ is τ and N is M  ,
τβ µ
(ii) or there is a system N  and moves (I after µ)  N −
→ (I after µ)  N  and I  M  −
→
(I after µ)  N  .

Diagrammatically we can say that given

then either µ is τ and N is M  , or there exists commuting moves:

In such diagrams we use the solid lines to indicate the moves that are given, and
the dotted lines those that are required.
 6.3 Describing bisimulations 205

Proof: Intuitively the reason why this is true is that if I  M −τ→ β

I  M  and
I  M does any different move then both moves must have occurred in different
independent components of M . Formally the proof proceeds by induction on the
inference of I  M −τ→ β
I  M  , with a sub-induction when appropriate on the
µ
derivation of I  M −→N . We proceed by examining the last rule used in the former
derivation.
All the axioms are trivial; these are the annotated versions of the axioms in
Figure 6.2, and in each case the required clause (i) holds.
Note that the rule (l-comm) from the same figure does not occur in any derivation
of a β-move. So for the inductive case this leaves one of the three instances of the
contextual rule, (l-ctxt). As an example suppose I  M1 | M2 −τ→ β
I  M1 | M2
τβ 
because I  M1 −→ I  M1 . We now examine the proof of the second move, which
µ
must be of the form I  M1 |M2 −→( I after µ)  N . There are three possibilities for
this move:

µ
• N is M1 | M2 and I  M2 −→ (I after µ)  M2 .
Diagrammatically we have

Here the second clause (ii) is automatically fulfilled, with the required N  being M1 | M2 .
To see this note that the first part of the previous lemma can be applied to I M1 −τ→I
β
M1
τβ 
to obtain (I after µ)  M1 −→ (I after µ)  M1 and an application of (l-ctxt) gives
the move (I after µ)  M1 | M2 −τ→ β
(I after µ)  M1 | M2 .

Since the free names of M1 are contained in those of M1 , the contextual rule (l-ctxt)
µ µ
can be applied to I  M2 −→ (I after µ)  M2 , to obtain the move I  M1 | M2 −→
 
I  M1 | M2 . In other words we have the required commuting diagram
206 Behavioural equivalences for aDpi
α α
• The label µ is τ , N is (new ẽ : D̃)(M1 | M2 ) and I1  M1 −→
1
I1  M1 , I2  M2 −→
2

I2 M2 , for some suitable labels α1 , α2 . In other words we have to complete the diagram:

(6.2)

First note that we also have the diagram

that can be completed, by induction, as

We use these commuting moves to construct the moves required to complete the diagram
(6.2) above:

An application of (l-comm) to I  M1 −α→

1
I after α1  M1 and I2  M2 −α→
2
I2  M2 ,
gives the first required move:
τ
I  M1 | M2 −→ I  (new ẽ : D̃)(M1 | M2 )
 6.3 Describing bisimulations 207

The second is obtained from I after α1  M1 −τ→ β

I after α1  M1 ; note that by the
first part of the previous lemma the environment used here, I after α1 , can be replaced
by any environment I  for which I   M1 is a configuration. An argument using subject
reduction, (3) on page 199, can be made to show that this includes I, ẽ:D̃
; the reasoning
depends on whether α is an input or output action. Then two applications of (l-ctxt)
gives the required

I  (new ẽ : D̃)(M1 | M2 ) −τ→

β
I  (new ẽ : D̃)(M1 | M2 )
µ
• The final possibility is that N is M1 | M2 and I  M1 −→ I  M1 . Here the argument is
a simpler form of the one we have just made, and is left to the reader.

This result is lifted to sequences of β-moves, by the use of some more convenient
µ̂
notation. Extending the ˆ notation introduced in Chapter 1, let I  M −→ I   N if
µ
• I  M −→ I   N , whenever µ is an external action
τ
• I  M −→ I  N , or I = I  and N = M , whenever µ is an internal action, that is τ
annotated or not; so τ̂ represents 0 or 1 internal moves.
τβ ∗ µ
Corollary 6.7 Suppose I  M − → I  M  . Then for every move I  M − → (I after
τβ ∗
µ)  N there is a system N  and moves (I after µ)  N − → (I after µ)  N  and
µ̂
I  M −→ (I after µ)  N  . Diagrammatically given

there exist commuting moves such that

Proof: By repeated application of the previous lemma.

Thus in some sense sequences of β-moves do not affect the possible occurrence of
other moves. For this reason they preserve bisimulation equivalence.
208 Behavioural equivalences for aDpi
τβ ∗
Proposition 6.8 Suppose I  M −
→ M  . Then I |= M ≈bis M  .

Proof: It is sufficient to prove this result in the case when I  M −τ→

β
M  . Let R be
the parameterised family of relations defined by letting I |= M R M  whenever

• I  M is a configuration
τβ
• either M = M  or M −→ M .

We show R is a bisimulation; note that the individual relations RI are not

necessarily symmetric.
µ
Let I |= M R M  and first suppose that I  M −→ N . If M and M  are the same
then the matching move is trivial. Otherwise we know I  M −τ→ β
M  and we can
apply Lemma 6.6, which gives two cases; both result in the required matching move.
τ ∗
In the first case µ is τ and the matching move is the empty one I  M  −→ M ,
since N and M  coincide. In the second it is the move furnished by the lemma,
µ
I  M  −→ N  , since (I after µ) |= N R N  .
µ
Suppose on the other hand that I  M  −→ N  . If M −τ→ β
M  then the required
τβ  µ 
matching move from I  M is simply I  M −→ M −→ N .

This result gives us many useful instances of bisimulation equivalence, all albeit
expected. Examples include
I |= k
P | Q ≈bis k
P  | k
Q
I |= k
rec z. B ≈bis k
P{|rec z. B/z|}
(6.3)
I |= k
(newc c : C) P  ≈bis (new c@k : C)(k
P 
I |= k
goto l.P  ≈bis l
P 
assuming of course that I is such that all of these are configurations.
More importantly β-moves enable us to develop a notion of bisimulation-up-
to-β-reduction, which can cut down considerably on the complexity of exhibiting
bisimulations. The general idea is to define a modified bisimulation relation R in
which the condition for matching residuals is relaxed; instead of demanding that
they be again related by R we allow an approximate matching. We have already
seen one instance of this, where the approximation is implemented with structural
equivalence. Here we use β-moves; our formulation takes advantage of the fact
that both −τ→
β ∗
and structural equivalence, ≡, can be viewed as relations over both
systems and configurations. Most of the abstract reasoning we are about to perform
is independent of the precise syntax for configurations, and holds in an arbitrary lts.
Consequently we will often use general meta-variables such as C , D to range over
configurations; indeed the previous two results, Corollary 6.7 and Proposition 6.8
could also have been treated at this level of abstraction.
 6.3 Describing bisimulations 209

Definition 6.9 (β-transfer properties) A relation S over aDpi configurations is said

to satisfy the strong β-transfer property if

for some label µ such that µ ∼ µ , where Al , Ar are the approximation relations

(−τ→
β ∗
)◦ ≡ and ≈bis
µ
respectively. In other words the move C −→ C  need only be matched by a move
µ


D =⇒ D where some β-residual of C  is approximately related to D . This means
the existence of C  −τ→
β ∗ 
C such that

C  ≡ ◦ S ◦ ≈bis D

On the other hand we say S satisfies the weak β-transfer property if

for some label µ such that µ ∼ µ . 

These relations allow considerable flexibility in how actions are matched, with the
result that they are in general much smaller than real bisimulations. Intuitively in
such an S the single pair C , D
represents any pair C  , D
, where D ≈bis D , and
C β-reduces to some configuration structurally equivalent to C  .

Definition 6.10 (bisimulation up-to-β) We say that a relation R over configurations

is a bisimulation-up-to-β if it and its inverse R−1 satisfy the strong β-transfer
property. 

As with standard bisimulations, we tend to present these relations over

configurations in terms of families of relations over systems, parameterised by type
210 Behavioural equivalences for aDpi

environments, as explained on page 201. This presentation is used in the following

example.
Example 6.11 Let DelP and DelS denote the following systems
k
goto l. (del! v1
| del! v2
| del! v3
) 
k
goto l.del! v1
| (goto l.del! v2
| goto l.del! v3
) 
respectively. DelS is a system that delivers, from k to l, three values v1 , v2 , v3
in a sequential manner; each value is transported individually, by migrating an
individual process for it. On the other hand DelP transports all three simultaneously,
in one migration.
Suppose Id is a type environment that can type both systems. This means
Id  k : loc
Id  l : loc[del : w Tv
]
Id l vi : Tv
for some appropriate type Tv . Then the relation
RI = { (M , M ) | I  M is a configuration }
∪ { DelP, DelS
| if I ≡ Id }
is a bisimulation-up-to-β.
To see this let Dvl denote the system
l
del! v1
 | l
del! v2
 | l
del! v3

Then it is easy to check that
• DelS and DelP both reduce via β-moves to Dvl
• every β-residual of DelS and DelP can be reduced, via β-moves, to Dvl.

Formally to show that R is a bisimulation-up-to-β-moves it is sufficient to show

that all initial derivatives of (Id  DelS) and (Id  DelP) are correctly matched.
For example the only possibility from DelS is
τ
Id  DelS −→ Id  N1
where N1 is k
goto l.del! v1
 | k
goto l.del! v2
| goto l.del! v3
; in fact this
is a β-move. This can be matched by the move
τ ∗
(Id  DelP) −→ (Id  Dvl)
(again a sequence of β-moves) since (Id  N1 ) Al ◦ R ◦ Ar (Id  Dvl).
It is possible to construct a standard bisimulation containing the pair
DelP, DelS
, but it is much more difficult, since explicit relationships must be
enumerated for all of the β-residuals.

 6.3 Describing bisimulations 211

The relevant properties of the left-hand approximation relation are given by:
Lemma 6.12
• Al ⊆ ≈bis
• Al ◦ Al = Al , that is Al is idempotent.

Proof: Note that Al is a relation both over configurations and over systems; here
we view it as being over configurations.
The proof of the first property is straightforward, in view of Proposition 6.8.
To prove the second, let Id denote the identity relation on configurations. Since
τb ∗
Id ⊆ (−→ ) and Id ⊆ ≡ it follows trivially that Id ⊆ Al . Therefore Al ⊆ Al ◦ Al ,
because if C Al D then we have C Al C Al D.
So we prove the converse, and for the sake of variety let us reason directly on
the relations. First note that expanding out Al ◦ Al we get
τb ∗ τb ∗
−→ ◦ ≡ ◦ −→ ◦ ≡ (6.4)
However the second part of Lemma 6.5 implies
τb ∗ τb ∗
≡ ◦ −→ ⊆ −→ ◦ ≡
τb ∗ 
For if D ≡ ◦ −→ C then we know that there is some C such that D ≡ C and
τb ∗  τb ∗ 
C −→ C . Repeated application of the lemma to C −→ C gives some D such that
τb ∗  τb ∗
D −→ D and D ≡ C  . The existence of this D ensures that D −→ ◦ ≡ C.
So (6.4) above can be rewritten to
τb ∗ τb ∗
−→ ◦ −→ ≡ ◦ ≡
that coincides with Al , since both component relations are transitive.

Lemma 6.13 Al satisfies the following transfer property:

Proof: Here let us argue diagrammatically. Suppose

212 Behavioural equivalences for aDpi

This actually means that there exists some C1 such that

By Corollary 6.7 we can find a C1 such that

Then the second part of Lemma 6.5 allows us to find D such that

The result now follows, since this means C  Al D .

Proposition 6.14 Suppose S is a relation over configurations that satisfies the

strong β-transfer property. Then it also satisfies the weak β-transfer property.
Proof: Suppose

µ
We use induction on the size of the action-in-context C =⇒ C  to show the existence
of some D such that

(∗)
 6.3 Describing bisimulations 213
τ µ
and µ ∼ µ . Here size means the number of actual strong moves −→ and −→ used
µ
in the derivation of C =⇒ C  . There are three cases.

µ
• Suppose C −→ C  . Then the result follows from the strong β-transfer property.
τ µ
• Suppose C −→ C1 =⇒ C  . Applying the strong transfer property to

gives

This means we have C1 Al C2 S D2 Ar D1 . Repeated application of Lemma 6.13 to

gives

µ̂
Here the essential point is that the size of the derivation C2 =⇒ C2 is at most that of
µ 
C1 =⇒ C . So we may apply induction to
214 Behavioural equivalences for aDpi

to obtain

for some µ ∼ µ. Now we can use the fact that D2 Ar D1 , that is D2 ≈bis D1 , to obtain


a move D1 =µ⇒ D such that D2 Ar D . The matching move required in (∗) above is
τ̂ µ

D =⇒ D1 =⇒ D , since by the second part of Lemma 6.12 C  Al ◦ S ◦ Ar D .
µ τ
• The final possibility, which we leave to the reader, is that C −→ C1 =⇒ C  ; the proof is
similar to the case we have just completed.

This result is the essential ingredient in the proof that bisimulations-up-to-β yield
bisimulation equivalence.
Theorem 6.15 If I |= M R N , where R is a bisimulation-up-to-β, then I |=
M ≈bis N .
Proof: Let S denote the relation ≈bis ◦ R ◦ ≈bis over configurations. We show that
this is a bisimulation, from which the result follows. The proof relies on the fact
that R and its inverse satisfy the weak β-transfer property, which we know to be
true from the previous proposition.
First suppose

We have to find a matching move

(∗∗)

Now C S D actually means

C ≈bis C1 R D1 ≈bis D

µ
So we can find a move C1 =⇒ C1 such that C  ≈bis C1 . Since R satisfies the weak

µ 
β-transfer property we can find a move D1 =⇒ D1 such that
C1 Al ◦ S ◦ Ar D1
 6.4 Servers and clients 215

But Lemma 6.12 ensures that Al ⊆ ≈bis and therefore we actually have C  S D1 ;


recall that Ar is actually ≈bis . Now since D1 ≈bis D we can find a move D =µ⇒ D
such that D1 ≈bis D . This is the matching move required in (∗∗) above, since
C  S D .
Note that the relation S is not necessarily symmetric, since R may not be. So we
µ
have to also prove that every move from D, D −→ D , must be properly matched
by an appropriate one from C . However the argument is essentially the same, but
this time relying on the fact that R−1 satisfies the weak β-transfer property.

Referring back to Example 6.11, the exhibited bisimulation-up-to-β, is therefore

a straightforward demonstration that
DelS ≈bis DelP

6.4 Servers and clients

Let us now revisit another example, the server that checks whether integers are
prime, from Example 5.1, s
DprimeS, where DprimeS is the following code
installed at a site s:
DprimeS ⇐ rec z. (z | inp ?(x, y@w) goto w.y! isprime(x)
)
We would like to prove that in some sense this does indeed act like a prime-checking
server. Of course this server requires clients using it to conform to the required
protocol; namely a client must send, in addition to the integer to be checked, a
return address of the appropriate type on which the answer is to be returned. The
format for such clients has already been given, also in Example 5.1. These must
take the form h
Client(v), where
Client(v) ⇐ (newc r : R) (goto s.inp ! v, r @h
| r?(x) print! x
)
and R is the type rw bool
.
As explained in Example 5.16, the clients use the channel inp , located at s, at type
w Tin
, and the server uses it at type r Tin
, where Tin is the type (int, w bool
@loc).
So assuming  assigns the type rw Tin
to inp at site s and w bool
to print at the
sites h1 , h2 , one might expect
 |= s
DprimeS | h1
Client(27) | h2
Client(11)
≈bis (6.5)
s
DprimeS | h1
print! false
 | h1
print! true

to be true. This would show, for example, that different clients can use the service
simultaneously, with each client getting its correct response.
216 Behavioural equivalences for aDpi

But unfortunately this statement is not true. The basic reason is that this
framework allows a context in which there is another server, providing a different,
perhaps unexpected, response to requests on the resource inp at site s; we have
already come across this argument, in a slightly different setting, in Example 3.15.
Consider the system
s
badServer
where badServer is the code

inp ?(x, y@w) goto w.y! true

This server, which also uses inp at s with the type r Tin
, simply decrees that
all integers are prime. Now if the statement (6.5) above were true, then since
  s
badServer, the compositionality principle would dictate that

 |= s
DprimeS | h1
Client(27) | h2
Client(11) | s
badServer

≈bis
s
DprimeS | h1
print! false
 | h1
print! true
 | s
badServer

would also be true. But this is obviously not the case. In the first system, the client at
h1 could communicate with badServer, and get back the answer true and print it.
This behaviour is not possible in the second system. Formally the first configuration
can perform the weak move
h1 . print!(true)
========⇒
and this cannot be matched by the second.
Nevertheless we would still like to prove that the server/client interaction works
correctly, provided s
DprimeS is the only server in the environment. By restricting
the type environment  we can prove a slightly stronger result; in any environment
in which the read capability on inp is not available, the statement (6.5) above is
true.
As a first step towards this proof we consider a slightly simpler situation.

Example 6.16 Let Is be any environment that satisfies

Is hi print : w bool

Is s inp : w Tin
where Tin is (int, w bool
@loc)
Is s inp : T implies w Tin
<: T

So we confine our contexts to those in which inp @s can only be used to send values,
of the appropriate type.
 6.4 Servers and clients 217

Let DprimeS1 be the code

inp ?(x, y@w) goto w.y! isprime(x)

This code, placed at the server site s, responds correctly to one client request. We
show this formally by proving
Is |= s
DprimeS1  | h1
Client(27) ≈bis h1
print! false
 (6.6)
Let R be the relation over configurations consisting of all pairs of the form
Is  Ml , Is  Mr

where Ml , Mr
ranges over the following pairs:
s
DprimeS1  | h1
Client(27) ↔ h1
print! false

(new r @h1 : R)(s
DprimeS1 |
s
inp ! 27, r
 | h1
wait) ↔ h1
print! false

(new r @h1 : R)(h1
r! false
 | h1
wait) ↔ h1
print! false

h1
print! false
 ↔ h1
print! false

0 ↔ 0
Here wait is the code r?(x) print! x
.
Then it is easy to check that R is a bisimulation-up-to-β. For example the only
possible move from an instance of Is  Mr is
s. print!(false)
Is  Mr −−−−−−−→ h
stop
This can be matched by a move from any corresponding I  Ml . For example if
Ml is
(new r @h1 : R)(h1
r! false
 | h1
wait)
then the required move is
τ s. print!(false)
Is  Ml −→ −−−−−−−→ (new r @h1 : R)(h
stop)
This follows since one can show
(new e : D) M ≡ M
whenever bn(e) does not occur free in M ; and of course from (s-zero) in Figure 5.4
we have h
stop ≡ 0; see Question 1 at the end of Chapter 5.
Similarly all the moves from Is  Ml can be matched by the corresponding
Is  Mr ; in fact other than the actual print move, the matching is by the empty
move. For example suppose Ml is
(new r @h1 : R)(s
DprimeS1  | s
inp ! 27, r
 | h1
wait)
218 Behavioural equivalences for aDpi

Then the only possible move is the communication of the value 27 to the server:
τ
Is  Ml −→ Ml
where Ml denotes (new r @h1 : R)(s
goto h1 .r! false
 | s
stop | h1
wait). The
required matching move is
τ 0
Is  Mr −→ Mr
This is because
Ml −τ→
β
(new r @h1 : R)(h1
r! false
 | s
stop | h1
wait)
and this latter system is structurally equivalent to (new r @h1 : R)(h1
r! false
 |
h1
wait), which in turn is related to Mr at Is by R.
This ends our proof of the statement (6.6) above.

It would be tempting to use this result, (6.6), to establish the more general
Is |= s
DprimeS | h1
Client(27) ≈bis s
DprimeS | h1
print! false
 (6.7)
By exhibiting a specific bisimulation-up-to-β, it is possible to show
Is |= s
DprimeS ≈bis s
DprimeS | s
DprimeS1 
An application of (compositionality) then gives
Is |= s
DprimeS | h1
Client(27) ≈bis s
DprimeS | s
DprimeS1 |
h1
Client(27)
since Is  h1
Client(27). From this we could then conclude (6.7), again by
(compositionality), under the hypothesis
Is  s
DprimeS
But unfortunately this hypothesis is not true; indeed the knowledge environment
was designed to explicitly rule out systems that can read from the request service
inp at s.
However we can establish (6.7) directly by giving a witness bisimulation-up-to-β
slightly more complicated than that in Example 6.16.
Example 6.17 Let S denote the system
s
inp ?(x, y@w) goto w.y! isprime(x)
| DprimeS
Note that s
DprimeS −τ→
β
S and therefore by Proposition 6.8
Is |= s
DprimeS ≈bis S.
In this example we will show
Is |= S | h1
Client(27) ≈bis S | h1
print! false
 (6.8)
 6.4 Servers and clients 219

Note that Is  h1
Client(27) and Is  h1
print! false

. Therefore our second
goal (6.7) will follow by (compositionality).
Let R be the relation containing all pairs of configurations

I  Ml , I  Mr

that satisfy the following requirements:

(i) Mr is of the form
h1
print! false
 | B | S
where B is a system

j∈J hj
rj ! bj

for some index set J , and collection of names hj , rj and boolean values bj . Here

j∈J Mj represents a series of systems Mj running in parallel, one for each index in J .
(ii) Ml takes one of the forms
(a) h1
Client(27) | B | S
(b) (new r @h1 : R) s
inp ! 27, r @h1
 | h1
wait | B | S
(c) (new r @h1 : R) h1
r! false
 | h1
wait | B | S.
(iii) I satisfies the requirements on Is given in Example 6.16, together with

I  hj : loc
I hj rj : w bool

Note that the pair

Is  h1
Client(27) | S, Is  h1
print! false

 | S

is in R, simply by taking the index set in the system B to be empty. So (6.8)

follows if we can show that R is contained in a bisimulation-up-to-β. In fact if Id
denotes the identity relation over configurations then (R ∪ Id) turns out to be a
bisimulation-up-to-β. This requires a considerable amount of checking, but all of
it is mundane.
For example consider a move from I  Mr . There are three possibilities:
• It is the print action at h1 ;
h1 . print!false
I  h1
print! false
 | B | S −−−−−−−→ h1
stop | B | S

But this can be matched precisely by every possible Ml , as

τ ∗ h1 . print!false
I  Ml −→ −−−−−−−→ M 

for some M  structurally equivalent to h1
stop | B | S; the presence of the relation Id is

necessary to take care of this possibility.
220 Behavioural equivalences for aDpi

• It is a move from S. Here there are a number of possibilities, depending on whether the
location and/or the channel received on inp at s is fresh. When both are fresh we get
moves of the form
αi
Ih1
print! false
 | B | S −→
h1
print! false
 | B | s
goto h.r isprime(vj )
| DprimeS (6.9)
where αi is the action (h : H, r @h : Tr )s.inp ?(v, r @h). Note that this action can be
continued, via τβ moves, to a system that is once more of the form Mr , up to structural
induction:
h1
print! false
 | B | s
goto h.r isprime(v)
| DprimeS −τ→
β ∗

h1
print! false
 | (B | h
r! isprime(v)
) | S
Each possible Ml can allow the S component to execute the same input action, followed
by a τ move to obtain
I  Ml =α⇒
i
M
for some M  that is once more of the required form Ml . Here matching the residuals is
with respect to the augmented environment I after αi , which unravels to I, h:H
, r @h :
Tr . Note that requirements (iii) above are satisfied by this environment, because the
action-in-context (6.9) can only be inferred provided
I, h:H
, r @h : Tr s r @h : w bool
@loc
There are a number of mild variations to the exact form of αi in the move (6.9) above;
for example it could be (r @hj : Tr )s.inp ?(r @hj ), for some hj already known to I. But in
each case the reasoning is more or less the same.
• Finally it might be a move from B. Here we can argue as in the previous case that it can
be matched by a similar move from I  Ml ; indeed in this case reasoning up-to-β is not
necessary.

We also have to consider all possible moves from each of the forms of Ml . If B
or S is responsible arguments similar to those already employed can be repeated.
As an example of the remaining cases let us consider when Ml has the form (a) and
the move is
Ih1
Client(27) | B | S −τ→
β

(new r1 @h1 : R) h1
goto s.inp ! 27, r @h

| wait | B | S
Now this move can also be continued via τβ steps, to reach a system that is once
more of a form required on the left-hand side Ml :
(new r1 @h1 : R) h1
goto s.inp ! 27, r1 @h
| wait | B | S −τ→
β ∗

(new r1 @h1 : R) s
inp ! 27, r

 | h1
wait | B | S
 6.5 Modelling a firewall 221

This can now be matched by the empty move from the right-hand side:
τ̂
IMr =⇒ Mr
The remaining possibilities of moves from the left-hand side are treated similarly; in
each case the corresponding move from the right-hand side is the empty move.

So we have established that one client can interact successfully with the server,
(6.7) above:
Is |= s
DprimeS | h1
Client(27) ≈bis s
DprimeS | h1
print! false

But simple compositional reasoning can now be used to generalise this to an
arbitrary number of clients. As an example let us consider a second client
h2
Client(11), and let us assume that Is also types this correctly; that is, it knows
that h2 is a location. Then, since Is  h2
Client(11), (compositionality) applied
to (6.7) gives
Is |= s
DprimeS | h1
Client(27) | h2
Client(11)
≈bis s
DprimeS | h1
print! false
 | h2
Client(11) (6.10)
A repeat of the argument in Example 6.17 establishes
Is |= s
DprimeS | h2
Client(11)
≈bis s
DprimeS | h2
print! true

A further application of (compositionality) to this, gives
Is |= s
DprimeS | h2
Client(11) | h1
print! false

≈bis s
DprimeS | h2
print! true
 | h1
print! false

Then, by the transitivity of ≈bis , and the commutativity of |, (6.10) gives
Is |= s
DprimeS | h1
Client(27) | h2
Client(11)
≈bis s
DprimeS | h1
print! false
 | h2
print! true

This argument can be extended to demonstrate that the server can properly handle
an arbitrary number of clients.

6.5 Modelling a firewall

Intuitively a firewall is an administrative domain to which access is restricted; only
agents that are permitted, in some sense, by the firewall are allowed in. A simple
example of such a firewall is given by
F ⇐ (new f : F) f
Inform | P 
222 Behavioural equivalences for aDpi

where Inform is the code

rec z. (z | goto a.tell! f

)
Here f is the name of the firewall, which is created with the capabilities described
in the location type F, and P is some code that maintains the internal business of
the firewall. A typical example of the capabilities of a firewall could be given by

F = loc[info : rw I
, req : rw R
]
that allows access to two resources info and req in f. Then P could, for example,
maintain appropriate services at these resources; of course P would also be able to
use non-local resources it knows about in its current environment.
In this very simplified scenario the existence of the firewall is made known
to only one (trusted) agent, a, which is strictly speaking another domain, via the
information channel tell located at a; a more realistic scenario would have some
method for generating such trusted agents. A typical example of the code for this
trusted agent is given by

A ⇐ a
tell?(x) goto x.Q | R

where a is informed of f by inputting on the local channel tell: we have the execution

F | A −→∗ (new f : F)(f
P | Inform | f
Q) | a
R (6.11)

and the code Q is allowed to execute locally within the firewall.

Moreover the resources to which Q has access within the firewall are controlled
by the capability type associated with the information channel tell. For example
suppose the type associated with this channel is rw Fr
where

Fr = loc[info : w I
, req : r R
]

a supertype of the declaration type F. Then in (6.11) Q, having gained entry into
the firewall, can only write to resource info and read from req.
Let us now consider the correctness of this simple protocol for allowing access
to one agent, a to the firewall. Let  be any type environment such that

  F |A (6.12)

Then one might expect to be able to derive

 |= F | A ≈bis (new f : F) f
Inform | P | Q | a
R (6.13)

But this happens not to be true, because of an implicit assumption; namely that the
information channel tell can only be accessed by partners in the entry protocol, f
and a; we have already seen this phenomenon when considering servers and clients.
 6.5 Modelling a firewall 223

In order for (6.12) to be true we must have  a tell : rw Fs

, and this allows other
agents in the environment access to tell. For example consider
Rogue ⇐ b
goto a.tell! b

and suppose that   Rogue. Then (compositionality) applied to (6.13) would give
 |= F | A | Rogue ≈bis (new f : F)(f
Inform | P | Q) | a
R | Rogue
But this is obviously not the case. The left hand system can reduce via a series of
τ steps (representing the interaction between A and Rogue) to the state
F | a
R | b
Q
Under reasonable assumptions about the code Q, the right-hand system has no
corresponding reduction to a similar state. On the left-hand side the code Q is
running at the site b while on right-hand side it is executing at f. Thus (6.13) cannot
be true.

However, as with the previous example on the server and its clients, our
framework allows us to amend the correctness statement (6.13) above, to take into
account the implicit assumption about the information channel tell. The essential
point is that the protocol works provided that only the firewall can write on tell. This
can be formalised by proving the equivalence between the two systems relative to
a restricted environment, one that does not allow write access to tell.
Suppose I is a type environment that satisfies
(i) I a tell : T implies r Fr
<: T
(ii) I  a
R
(iii) I  (new f : F) f
P.

The import of the first requirement, which is the most important, is that systems
in the computational context cannot write on tell. The other requirements, which
are mainly for convenience, ensure that the residual behaviour at a and f is well-
behaved, although a side-effect is that they also cannot write on tell. Note that in (iii),
because we are using aDpi, the capabilities in the firewall type F are expected to
be registered resources. Under these assumptions we prove
I |= F | A ≈bis (new f : F)(f
Inform | P | Q) | a
R (6.14)

First note that (up to structural equivalence)

F | A −τ→
β
F | At | a
R
via (l-split), where we use At as a shorthand for a
tell?(x) goto x.Q. So by
Proposition 6.8 it is sufficient to prove
I |= F | At | a
R ≈bis (new f : F)(f
Inform | P | Q) | a
R
224 Behavioural equivalences for aDpi

Here assumption (ii) comes in useful, as by (compositionality) it is now sufficient

to prove
I |= F | At ≈bis (new f : F)(f
Inform | P | Q)
Here the left-hand side can be manipulated using the structural equivalence rules,
in particular (s-ext), thereby reducing the proof burden to
I |= (new f : F)(f
P | Inform | At ) ≈bis (new f : F)(f
Inform | P | Q)
An application of (scoping), Proposition 6.4, reduces this further to
I |= f
P | Inform | At ≈bis f
Inform | P | Q
Expanding further using β-moves, we get
τ
• f
P | Inform | At −→
β
f
P | f
Inform | At
τβ
• f
Inform | P | Q −→ f
Inform | f
P | f
Q.

So further applications of Proposition 6.8, and (compositionality), give the

requirement
I |= f
Inform | At ≈bis f
Inform | f
Q (6.15)
This we establish directly by exhibiting a particular bisimulation.
We define the parameterised relation R by letting
J |= M R N
whenever
(a) J  M is a configuration and N is the same as M
(b) or J ≡ I and
• M has the form f
Inform | At |
(j+1) (a
tell! f
)
• N has the form f
Inform | f
Q |
j (a
tell! f
)
for some j ≥ 0.

Proposition 6.18 The parameterised relation R defined above is a bisimulation

up-to-β.
Proof: Suppose J |= M RN . First let us see that actions-in-context from J M can
be matched by corresponding actions-in-context from J  N . In fact it is sufficient
to consider case (b) above, when J ≡ I and M and N are of the prescribed form.
The actions fall into one of three categories:
• Here f
Inform is responsible, so it takes the form
τ
I  M −→ I  f
Inform | goto a.tell! f
 | At |
(j+1) (. . .)
 6.5 Modelling a firewall 225

But

I  f
Inform | goto a.tell! f

 | At |
(j+1) (. . .)−τ→
β ∗
f
Inform|
a
tell! f
 | At |
(j+1) (. . .)

and this can be matched, up to structural equivalence, by essentially the same moves:
τ ∗
I  N −→ I  f
Inform | f
Q |
(j+1) (. . .)

• The second possibility is that the third component,

(j+1) (a
tell! f
) is responsible for
the action, which therefore must be a.tell!f . It is easy to see that I  N can perform
exactly the same action, to a related configuration.
• Finally the middle component At might be involved in the action. Note that the action
cannot be external, as a.tell?V cannot be performed by the environment. So it must be a
communication, of the form
τ
I  M −→ If  f
Inform | a
goto f.Q |
j (. . .)

But once more this can be matched, up-to-β, since

τ ∗
I  f
Inform | a
goto f.Q |
j (. . .) −→ β I  f
Inform | f
Q |
j (. . .)

and this can be matched by the empty sequence of internal actions from I  N .

We leave the reader to check the converse; namely that every action-in-context
from J  N can also be matched by actions from J  M . The details are similar,
but somewhat simpler.

This completes our proof of (6.14) above. Note that the firewall F allows in
principle multiple entries of agents from a. So, for example suppose R, in (6.14)
above, has the form
S | tell?(x) goto x.Q1
Let us show how the second agent, executing Q1 , can also gain access through the
firewall.
Let F1 denote the firewall containing the first agent Q:
F1 ⇐ (new f : F) f
P | Q | Inform
Then the reasoning we have just completed could be repeated, to prove
I |= F1 | a
R ≈bis (new f : F)(f
Inform | P | Q | Q1 ) | a
S 
This, combined with (6.14), gives
I |= F | A ≈bis (new f : F)(f
Inform | P | Q | Q1 ) | a
S 
Here the domain a has managed to send two separate agents into the firewall.
226 Behavioural equivalences for aDpi

6.6 Typed contextual equivalences

In Chapter 2 we put forward the idea that bisimulation equivalence should be looked
upon as a mechanism for providing a proof technique for relating systems, rather
than giving a definitive notion of when systems should be considered behaviourally
equivalent. Here we pursue this idea, applying it to aDpi; we define a touchstone
behavioural equivalence for aDpi, and examine its relationship with bisimulation
equivalence. There are two complications to the scenario discussed in Section 2.5,
namely types and locations. We need to generalise the definition of reduction barbed
congruence, Definition 2.25 so as to take these into account.
As argued in Chapter 4, the presence of types means that behavioural equivalences
have to move from relating processes, or their corresponding syntactic category in
aDpi systems, to relating configurations. So we need to revisit the justification for
reduction barbed congruence, and recast it in terms of configurations.
Recall that this relation was defined to be the largest relation that satisfies
three intuitive properties; thus aPi processes are deemed equivalent unless they
can be shown to be distinguished by one of these properties. So we have to
generalise these properties, from relations over processes in aPi, to relations over
configurations in aDpi. However we will only wish to relate two configurations if
their external knowledge coincides. Therefore we revert to the technique we have
already been using informally for presenting bisimulations, representing relations
over configurations by parameterised families of relations over systems, which we
recall in the following definition:
Definition 6.19 (typed relations) A typed relation in aDpi, is any family of relations
R, parameterised over type environments I , which satisfies: M RI N implies
(I  M ) and (I  N ) are both configurations.
We continue using the suggestive notation
I |= M R N
to indicate that M and N are related by the component RI . 
We now generalise reduction barbed congruence, Definition 2.25, to a typed
relation, by in turn generalising its three defining properties to typed relations.
Definition 6.20 (typed observations in aDpi) Let M ⇓barb
I k.a if
• I r (a@k)↓def and I w (a@k)↓def
(ẽ:D̃)k.a!V
• M =====⇒ M  , for some M  , (ẽ : D̃) and V .
(ẽ:D̃)k.a!V
When I  M is a configuration this amounts to demanding I  M == ===⇒ I   M  ,
 
for some configuration I  M .

So observations are localised to specific locations, and note that the observer
requires both the read and write capability on the channel being observed.
 6.6 Typed contextual equivalences 227

We say a typed relation R preserves observations if

I |= M R N implies P ⇓barb
I k.a if and only if Q ⇓barb
I k.a
for all names k and a. 

The definition of reduction-closure is borrowed directly from Definition 2.24:

Definition 6.21 (reduction-closure) A typed relation R is reduction-closed, if each

of its individual components is in turn reduction-closed. That is I |= M R N
and I  M −→ I  M  implies I  N −→∗ I  N  for some N  such
that I |= M  R N  . 

The generalisation of contextuality, Definition 2.5, needs to take the presence of

the observer’s knowledge into account.

Definition 6.22 (typed contextual relations) A typed relation R is called contextual

if it satisfies:
• (Compositional) I|= M RN and I  O implies I|= M |O R N |O and I|= O|M R O|N .
• (Fresh weakening) I |= M R N implies I, e:D
|= M R N , whenever bn(e) is fresh
(to M , N and I).
• I, e:D
|= M R N implies I |= (new e : D) M R (new e : D) N , whenever both
I  (new e : D) M and I  (new e : D) N are valid configurations. 

The major change from the untyped case, Definition 2.5, is that we only expect
related systems to remain related when run in parallel with a restricted set of other
systems, namely those that can be typed by the current knowledge of the observers.
However knowledge of names is carefully managed by type environments and
so we also need to add a form of weakening. We expect contextual relations to
be preserved by inventing completely new names; with aDpi these could be new
locations, new resources at existing locations, or even new registered resources.

Definition 6.23 (reduction barbed congruence for aDpi) We use =

∼ to denote the
largest typed relation in aDpi that
• preserves typed observations
• is typed contextual
• is reduction-closed. 

Note that although typed relations are formally families of relations over aDpi
systems, the standard set theoretic operations, such as ⊆, ∪, ∩ can be defined
point-wise on them, and consequently it makes sense to talk of the largest typed
relation satisfying a collection of properties. 

This is the natural generalisation of Definition 2.23 to typed relations. Indeed

we use the same notation, =,
∼ for the two concepts; it should be apparent from the
228 Behavioural equivalences for aDpi

context whether it refers to a relation over untyped processes from aPi or a typed
relation over systems in aDpi, that is a relation over aDpi configurations.
This behavioural equivalence inherits all the advantages and disadvantages
discussed in Section 2.5. The advantages include:
• It is intuitively reasonable, as systems are only distinguished on the basis of three
intuitively appealing behavioural properties.
• It takes into account the observer’s current knowledge of the capabilities of systems, in
a manner consistent with the ideas elaborated in the introduction to Chapter 4.
• By definition it satisfies the compositionality principle, given in (4.3).

The major disadvantage is that in general it is difficult to prove that two systems
are equivalent relative to a given I . To emphasise this let us attempt such a proof.
Example 6.24 Let us revisit the located memory m
LMem discussed in
Examples 5.17 and 5.6. In order for a client to use the memory it needs to know the
access methods at the appropriate types get@m : w Tg
, put@m : w Tp
. Suppose
on the contrary that Ir is some type environment that has no entries for get@m and
put@m. Then one would expect
Ir |= m
LMem =
∼0 (6.16)
to be true; this formalises the intuitive idea that knowledge of the memory’s access
methods, and their location, is necessary in order to use it.
To prove (6.16) we need to construct a typed relation R, which satisfies the three
defining properties of =,
∼ such that
Ir |= m
LMem R 0
The obvious approach is to define the family of relations R inductively as the least
ones such that
• m
LMem RIr 0
• for every I, M RI N implies M | O RI N | O and O | M RI O | N for every O
such that I  O
• M RI , e:D
N implies (new e : D) M RI (new e : D) N
• M RI N implies M RI , e:D
N , whenever the bound name of e is fresh to I, M , N .

Note that for many I , the relation RI is actually empty.

This gives a typed relation that by definition is contextual. But the difficulty is to
show that it is reduction-closed; if I |= M R N and M −→ M  then we need to find
a corresponding N  such that N −→∗ N  and I |= M  R N  . We could try to proceed
by induction on the derivation of the move M −→ M  . The base case is vacuous but
how to proceed for the inductive cases is far from obvious. For example consider
the case when M , N have the forms M1 | O, N1 | O for some I  O respectively,
and M1 R N1 . Here we need to match every move I  M1 |O −→ S with a matching
 6.6 Typed contextual equivalences 229

one from I  N1 | O. Unfortunately this move may arise through communication

between M1 and O, and there is no obvious way to proceed to find the matching
move.

However, as with aPi, bisimulations provide a conceptually convenient method

for establishing behavioural equivalences:
Proposition 6.25 I |= M ≈bis N implies I |= M =
∼ N.
Proof: A priori bisimulation equivalence can relate configurations with different
environments, and is therefore not a typed relation, as defined in Definition 6.19.
However our method of presenting witness bisimulations, as families of
parameterised relations over systems, allows us to transform ≈bis into a typed
relation.
Let B be the typed relation defined by letting I |= M B N whenever (I  M )≈bis
(I  N ). Then it is simply a matter of checking that B satisfies all the defining
properties of =.
∼ It is reduction-closed by definition, and it preserves observations
since bisimilar configurations must perform the same actions-in-context. Finally the
first two requirements for contextuality are covered by (B) and (C) on page 201;
the third follows from (scoping), Proposition 6.4, and strengthening for ≈bis , given
in (A) on the same page, page 201.
Since =∼ is the largest typed relation satisfying the defining properties the result
follows.

It is a trivial matter to show that Ir |= m
LMem ≈bis 0; the family of relations R

containing only one non-empty relation

Ir |= m
LMem R 0

is trivially a bisimulation, as neither configuration can make any action-in-context.

Consequently we can finish Example 6.24 and conclude

Ir |= m
LMem =
∼0
However the reader still familiar with the contents of Chapter 2 should easily be
able to establish that this proof method for =
∼ is not complete:
• I |= M = N does not necessarily imply I |= M ≈bis N .
∼
It is simply a matter of adapting Example 2.29 to the distributed language:
Example 6.26 Let Ia be a type environment in which k is a location and Ia k a:
rw. Then obviously

Ia |= k
a?a!  ≈bis k
stop

230 Behavioural equivalences for aDpi

because one of these systems can perform an action-in-context, namely an input

on a at k, while the other can perform no action-in-context. On the other hand by
adapting the proof given in Example 2.29 we can show
Ia |= k
a?a! =
∼ k
stop


6.7 Justifying bisimulation equivalence contextually in aDpi
The object of this section is to define a version of bisimulation equivalence that does
indeed coincide with the touchstone equivalence. The approach is straightforward;
we adapt the development in Section 2.7 and define an asynchronous bisimulation
equivalence for aDpi; this needs to take into account both the distributed nature of
computation, and the presence of types.
As argued in Section 2.6 the inadequacy of bisimulation equivalence lies
in the definition of the input actions-in-context. Consequently we define new
actions
α 
I  M −→ a I N

where α is an input label, of the form (ẽ : D̃)k.a?V . These are the least relations
satisfying the rules in Figure 6.3 and are based directly on those in Figure 2.6, which
define the untyped asynchronous actions for aPi. The rule (a-con) coincides with
the standard rule for inputing values, (l-in) from Figure 6.1, while (a-delv) is the
typed version of (a-delv) from Figure 2.6. The latter represents the delivery of the
value V to the channel a located at k, while the former represents its consumption.
Note that both require the environment to have the ability to send the value along a
at k. The two final rules (a-weak) and (a-ctxt) simply allow these asynchronous
actions to happen within evaluation contexts.
We leave the reader to check that the properties (1)–(5) on page 199 also apply to
these asynchronous actions-in-context, and we use the associated notation without
comment. The main extra property of these new actions is summarised in the
following result:
Proposition 6.27 (asynchronous actions) Let αi denote the input label
(ẽ : D̃)k.a?V and suppose I allows αi . Then
αi τ ∗ 
(i) I  M −→ a N implies I, ẽ:D̃
 M | k
a! V
 −
→ N , for some N  ≡ N .
τ ∗
(ii) Conversely, assuming (ẽ) are fresh to M , I, ẽ:D̃
 M | k
a! V
 − → N implies
αi  
I  M =⇒a N for some N ≡ N .

Proof: Part (i) is proved by induction on the derivation of the asynchronous action-
αi
in-context I  M −→ a N , and there are four cases, depending on the last rule applied;
in the first two αi is guaranteed to be of the simple form k.a?V .
 6.7 Justifying bisimulation equivalence contextually in aDpi 231

Figure 6.3 Asynchronous actions-in-context for aDpi

k.a?V
(a-con): Here we have I  k
a?(X ) R − −−→a k
R{|V/X |} because I w (a@k) ↓def and
I k V : I (a@k). But this information is sufficient to allow an application of (l-in)
w

to obtain the action-in-context

k.a?V
I  k
a?(X ) R −
−−→ k
R{|V/X |}
Now (l-comm), after an obvious application of (l-out), can be applied to obtain
τ
I  k
a?(X ) R | k
a! V
 −→ k
R{|V/X |} | k
stop
k.a?V
(a-delv): Here we have I  M − −−→a M | k
a! V
, and the result is trivial; I  M |
τ ∗
k
a! V
 −→ M | k
a! V
 in zero steps.
(a-weak): Here αi takes the form (e : D)βi , where βi is (d̃ : D̃ )k.a?V and
βi
I, e:D
 M −→ a N

We can apply induction to this action-in-context, which will actually give us the
required sequence of τ moves:
τ ∗ 
I, e:D
, d̃ :D̃
 M | k
a! V
 −→ N
(a-ctxt): We leave this case, which is similar, to the reader.

Let us now prove the converse, part (ii); we use induction on the number of steps
in the computation
τ ∗
I , ẽ:D̃
 M | k
a! V
 −→ N

zero: From the relation (I allows αi ), and the fact that (ẽ) are fresh, we have enough
information to enable an application of (a-delv) to obtain
k.a?V
I, ẽ:D̃
 M −
−−→a M | k
a! V

αi
Then the required move, I  M −→ a M | k
a! V
 follows by a series of applications
of (a-weak).
232 Behavioural equivalences for aDpi

non-zero: If the derivation is of the form

τ τ ∗
I, ẽ:D̃
 M | k
a! V
 −→ I, ẽ:D̃
 M  | k
a! V
 −→ I, ẽ:D̃
 N

we can apply induction. Otherwise the first step must involve an application of
(l-comm), and so the derivation takes the form
τ τ ∗
I, ẽ:D̃
 M | k
a! V
 −→ I, ẽ:D̃
 M  | k
stop) −→ I, ẽ:D̃
 N
βi
for some M  such that IM  M −→ M  , for some IM , where βi denotes the label
k.a?V . But I allows αi implies I, ẽ:D̃
allows βi , and so we can apply (2) on
βi  . Also synchronous actions-in-context are also
page 199 to obtain I, ẽ:D̃
M −→M
βi 
asynchronous, and so we have I, ẽ:D̃
 M −→ a M . Now a series of applications
αi 
of (a-weak) will give I  M −→a M .
τ ∗
Moreover in this case N must be of the form M  | k
stop, where M  −→ M  .
αi
Therefore the required asynchronous action-in-context is I  M =⇒a M  .

Following the development in Section 2.6, these revised input actions give rise
to an observational lts for aDpi. Here the configurations are of the form I  M , as
before, and the actions over configurations are given by
(ẽ:D̃)k.c?V
input: I  M − −−−−−→a I   N
(ẽ)k.c!V
output: I  M − −−−→ I   N
τ
internal: I  M −→ I N

This is called the asynchronous lts for aDpi, and for notational convenience, as in
µ 
Chapter 2, we will denote an arbitrary action in this lts by I  M −→ a I  N,
µ 
although in two cases this coincides with the standard action I  M −→ I  N .
Definition 6.28 (asynchronous bisimulations for aDpi) A relation over aDpi
systems is called an asynchronous bisimulation if it satisfies the standard transfer
properties in the asynchronous lts.
We let I |= M ≈a N denote the fact that there is some asynchronous bisimulation
R such that I  M R I  N . 

We leave the reader to check that this new equivalence corrects the mismatch in
Example 6.26 between bisimulation equivalence and reduction barbed congruence;
see Question 7 at the end of the chapter. Indeed the aim of this section is to show that
these asynchronous bisimulations capture exactly reduction barbed congruence.
Theorem 6.29 I |= M ≈a N implies I |= M = ∼ N.
Proof: It is simply a matter of checking that ≈a , viewed as a typed relation, satisfies
the defining properties of =,
∼ in Definition 6.23 applied to aDpi. By definition it
is reduction-closed, and it is simple to prove that it preserves typed observations.
The proof that it is contextual is, of course, non-trivial. However the proof of
Proposition 4.24 can be adapted to aDpi with asynchronous actions, as can that
 6.7 Justifying bisimulation equivalence contextually in aDpi 233

of Proposition 4.23. The final requirement, that I , n:D

|= M ≈a N implies
I |= (new e : D) M ≈a (new e : D) N , whenever both I  (new e : D) M and
I  (new e : D) M are configurations, requires a typed version of Proposition 2.20;
see Question 6 at the end of the chapter.

What this means is that in order to show I |= M = ∼ N it is sufficient to exhibit

an asynchronous bisimulation containing the configurations (I  M , I  N ). As
we have seen, in the untyped case of aPi, asynchronous bisimulations are not quite
as convenient to exhibit as synchronous ones. But synchronous bisimulations also
provide a sound proof method:
Proposition 6.30 I |= M ≈bis N implies I |= M ≈a N .
Proof: It is sufficient to show that ≈bis satisfies the requirements for being an
asynchronous bisimulation, as given in Definition 6.28. To this end suppose M ≈bis
µ 
N and I  M −→ a M ; we must find a matching asynchronous move from N . The
only non-trivial case is where µ is an input label, say αi = (ẽ : D̃)k.a?V , where
we need a move I  N =α⇒ i
N  such that (I after αi ) |= M  ≈bis N  .
τ ∗
From part (i) of Proposition 6.27 we have I , ẽ:D̃
 M | k
a! V
 −→ M  , for
some M  ≡ M  . Now ≈bis is compositional, and is preserved by fresh weakening;
see (B), (C) on page 201. This means that
I , ẽ:D̃
|= M | k
a! V
 ≈bis N | k
a! V

and so the above sequence of τ actions can be matched; we have
τ ∗ 
I , ẽ:D̃
 N | k
a! V
 −→ N (6.17)

for some N  such that I , ẽ:D̃

|= M  ≈bis N  . In fact this can be rendered as
(I after αi ) |= M  ≈bis N  . But part (ii) of Proposition 6.27 can now be applied
to (6.17), to obtain
αi 
I  N −→ a N

for some N  ≡ N  ; this is the required matching move.

Thus the various examples treated in Section 6.3, and the general proof methods
developed there, can now be considered to pertain to our touchstone equivalence, =.
∼
Our aim is to show that asynchronous bisimulations actually provide a complete
proof method; that is whenever I |= M = ∼ N we can exhibit an asynchronous
bisimulation R containing the pair (I  M , I  N ). However this is only true in
a restricted setting.
Example 6.31 Let  be any environment that types both the systems
k
b! a
 (new c@k : rw) k
b! c

234 Behavioural equivalences for aDpi

Let I be obtained from  by omitting the typing for a at k.

Then one can check (how?) that
I |= k
b! a
 =
∼ (new c@k : rw) k
b! c
 (6.18)
The problem is that any observer typeable by I does not know of the existence of
a and therefore cannot distinguish it from the completely new name c.

To avoid this kind of anomaly we restrict our attention to strict configurations.

Definition 6.32 (strict configurations) A configuration I  M is strict if there is a
type environment  such that
•  <: I
• M
• dom() ⊆ dom(I)

Note that it is only the last clause that is different from Definition 6.1; it requires
that all names necessary to type M must be at least known to I . 
µ
Proposition 6.33 Suppose I  M is a strict configuration. Then I  M −
→ I  M 
 
implies I  M is also a strict configuration.
Proof: From result (4) on page 199 we know that I   M  is a configuration;
that is   M for some  such that  <: I . To establish the current proposition
we re-do the proof of this result, mimicking that of the corresponding result for
aPi, Corollary 4.13, checking the extra requirement, that a   can be found whose
domain is contained within that of I  .
First suppose µ is the output action (ẽ:D̃)k.a!V , in which case I  is
I , V :I r (a@k)
@k, and subject reduction, (3) on page 199, gives , ẽ:D̃
 M  . A
careful analysis of the rules for generating actions-in-context will reveal that each
ei will actually appear in the domain of V :I r (a@k)
@k, from which it follows that
the required   is , ẽ:D̃
; such an analysis is given in Question 1 at the end of the
chapter.
Now suppose µ is the input label (ẽ : D̃)k.a?V . Here we know that I  is I , ẽ:Ẽ
,
where (ẽ) are fresh to I . They can also be assumed to be fresh to  and therefore
Question 5 of the previous chapter assures us that , ẽ:Ẽ
is a valid environment.
We can now mimic the input case in the proof of Corollary 4.13 to obtain , ẽ:Ẽ

M  , which establishes the required result.

So for the remainder of this section let us consider the restricted asynchronous
lts consisting only of strict configurations. The previous proposition means that
bisimulation equivalence is also well-defined in this restricted setting. Moreover
within this restricted setting we are able to repeat the general completeness argument
of the untyped setting of Section 2.7. But this time round it is considerably
 6.7 Justifying bisimulation equivalence contextually in aDpi 235

more complicated due to the presence of types, and the parameterisation of the
equivalences with respect to knowledge environments.
A typical example is the definability of actions-in-context, generalising
Theorem 2.37, in which contexts are defined for mimicking actions. These actions
are located, and the values that are sent and received may only make sense at the
location of the action. But we will need to manipulate these values, perhaps at
varying locations. Consequently we need to transform them into global values,
with global types.
Moreover, as in Theorem 2.37, we need to make available at some standardised
place the new names generated by the action we are defining. But here, in addition,
we need to also make available their capabilities, and even new capabilities on
names that are already known. So first let us develop some notation.
Definition 6.34 (standard environment extensions) The type environment , V :T

is said to be a standard extension of  if

• T is a global type
• for every component vi of V of the form u@w, if u@w is new to , that is, is not in dom(),
then    u : rc.

What this means is that new located channels in the extension cannot be registered
resources. 
µ 
Lemma 6.35 If I  M −
→ a M then (I after µ) is a standard extension of I .

Proof: If µ is the internal label τ then this is immediate, since I after τ coincides
with I . If it is the input action (ẽ : D̃)k.a?U then I after µ is I , ẽ:D̃
. There may
be a non-global entry in D̃, a local channel type C. But this can be replaced by the
global entry C@loc.
Also if c@l is new to I it must appear in (ẽ). Therefore we know, because of the
well-definedness of the label µ, that c must be new to I , and therefore is certainly
not a registered resource known to I .
When µ is the output action label (ẽ : D̃)k.a!U , the reason is the same. First
if c@l is new to I in I after µ, which in this case unravels to I , U :I r (a@k)
,
then c@l must again appear in (ẽ). This follows from subject reduction, (3) on
page 199, from which we can deduce that , ẽ:D̃
k U :  w (a@k), for some 
whose domain coincides with that of I . Secondly the types used in the extended
environment, I r (a@k), can easily be globalised, by replacing each occurrence of C
with C@loc.

So (I after α) always has the form I , V :T

, where V :T
represents the new
information learnt by performing the action. Let us use vI (α) to denote this value
V and tyI (α) the corresponding type T. Then the context we design for mimicking
236 Behavioural equivalences for aDpi

the performance of the action labelled α in the environment I will make available
the new information vI (α) at the type tyI (α) at some fresh location. To this end,
when discussing an action labelled α we use Ih to denote the extended environment
I , succ : rc rw tyI (α)

, fail : rc rw

,
h : loc, succ@h : rw tyI (α)
, fail@h : rw

where succ, fail, h are all assumed to be fresh to I . Here the location h may
be viewed as a home base at which information may be collected. But its actual
identity is not important. For if Ih |= M = ∼ N for a particular h, then we can assume
Ih |= M =N for any fresh h  , where I  is obtained from I in the obvious manner,
∼ h h
by renaming the entries at h, to h . This follows because = ∼ preserved by injective
is
renamings; see Question 10 at the end of the chapter.
Theorem 6.36 (definability in aDpi) Let α denote an external action, (ẽ : D̃)k.a!V
or (ẽ : D̃)k.a?V , and suppose I allows α. Then there is a system T (α) with the
following properties:
1. Ih  T (α).
2. If I  M is a strict configuration then
α  ∗ 
(a) I  M − → a M implies T (α) | M −→ (new ẽ : D̃)(h
succ! vI (α)
 | M )
∗
(b) T (α) | M −→ R, where R ⇓ barb h.succ and R  ⇓ barb h.fail implies that R is
structurally equivalent to (new ẽ : D̃ )(h
succ! vI (α)
 | M  ) for some M  such
α  
that I  M =⇒ a M , where α ∼ α .

Proof: First consider the output case. We give the proof for a specific instance
αo = (c@k : C)k.a! c, l
; the general case should be apparent from this example.
Let T (αo ) denote
h
fail! | k
a?(x, y) if P(x, y, l, I )
then goto h.fail?succ! x@k, y

else stop
Here P(x, y, l, I ) is shorthand for code that checks the incoming values at k, bound
to x and y, are what is expected; the second must be equal to l while the first must be
completely new. This means being completely new at k in the implicit underlying
type environment with respect to which we are working. But since we are restricting
attention to strict configurations this can be checked by ensuring that the first value
is not declared at k in the domain of I . So the testing code can be expressed as
if y = l then (if x  ∈ I then goto h.fail?succ! x@k, y
else stop) else stop
where in turn x ∈ I can be coded up as a sequence of tests of x against the names
b such that b@k is in the domain of I . The use of fail in T (αo ) is to be able to
 6.7 Justifying bisimulation equivalence contextually in aDpi 237

guarantee, by the absence of a barb on fail, that the output action and subsequent
tests have indeed occurred.
1. It is straightforward to show that the test is well-typed, Ih  T (αo ).
2. (a) Suppose I  M −α→ o
a N ; recall that synchronous and asynchronous outputs coincide.
Then an application of (l-comm) from Figure 6.2, followed by applications
of the (l-eq), and then (l-move) followed by another (l-comm) to affect the
synchronisation on fail, gives
τ ∗
I  T (αo ) | M −→ (new ẽ : D̃)(h
succ! c@k, l
 | N )
Now (6) on page 200 can be used to turn these τ moves into reductions.
(b) Finally suppose T (αo ) | M −→∗ R, where R ⇓barb h.succ and R  ⇓barb h.fail. Then
τ ∗
by the same point we also know I  T (αo ) | M −→ Rτ , where Rτ ⇓barb h.succ
and Rτ  ⇓ barb h.fail, since barbs are preserved by structural equivalence. Here the
inability to do a barb on fail is crucial; by examining the possible execution tree we
see that Rτ must be of the form (new ẽ : D̃ )(h
succ! c@k, l
 | M  ) for some M 

for which we can derive I  M =α⇒a M  , where α  ∼ α.

Now let us consider the input case, and again we only consider a typical example,
when αi is (c@k : C, d @l1 : C )k.a?(c, d @l1 , l2 ). Here the test has to generate the
new names, c at k and d at l1 and then send them, together with the existing l2 ,
along a at location k; at the same time it exports the new names, suitably globalised
at h. Let T (αi ) denote the system
h
fail! |
goto l1 .(new d : C ) goto k.(new c : C) a! c, d @l1 , l2
|
goto h.fail?succ! c@k, d @l1 , l2

Here we leave the reader to check that T (αi ) has the required properties; the
reasoning is similar to that in the proof of Proposition 6.27. Here the role of fail
is less important; it merely ensures that the various new names, declared locally,
have been exported to the systems level. However the use of the asynchronous
actions-in-context instead of synchronous ones is crucial, as the test T (αi ) cannot
guarantee that the actual communication along a at k has happened.

As in the untyped case for aPi, these tests do not provoke exactly the same
reaction in systems as the actions-in-context they are mimicking. When the test is
applied the bound names of the action still scope the residual of the system. We
need an extrusion lemma, generalising Lemma 2.38, which will allow us to strip
off these from the residuals. It helps to simplify the situation a little if we use a
slightly weaker version of =,
∼ which we call = ∼p .
Definition 6.37 (pcontextuality) A typed relation R is pcontextual if it is preserved
by parallel contexts and a restricted form of weakening. Referring to Definition 6.22,
238 Behavioural equivalences for aDpi

we only require that the first clause and special instances of the third clause be
satisfied. Specifically we say R is pcontextual if it satisfies:
• (Parallel) I |= M R N and I  k
P implies I |= M | k
P R Q | k
P and
I |= k
P | M R k
P | N .
• (Fresh location weakening) I |= M R N implies that for every location type L there is
some l fresh to I such that I, l:L
|= M R N . 

Let =∼p be the largest typed relation over processes that is reduction-closed,
preserves typed observations, and is pcontextual. Note that we only require
weakening with respect to some fresh location l. But it turns out that Weakening
follows for arbitrary fresh locations; see Question 10 at the end of the chapter. The
purpose of this restricted form of contextual equivalence is to facilitate the proof
of the following result.
Lemma 6.38 (extrusion for aDpi) Suppose I , V :T
is a standard extension of I ,
and that in the extended environment Ih the type of succ at h is rw T
. If
Ih |= (new ẽ : D̃) M | h
succ! V
 = 
∼p (new ẽ : D̃ ) N | h
succ! V
,
where each ei occurs in V then I , V :T
|= M =
∼p N .
Proof: We define the typed relation R by letting J |= M R N whenever
(i) J ≡ I, V :T
, for some standard extension of I
(ii) Ih |= (new ẽ : D̃)(M |h
succ! V
) = 
∼p (new ẽ : D̃ )(N |h
succ! V
), for some fresh
h, where we assume each ei occurs in V .

Note that in the decomposition of J we do not require the values in V to be fresh

to I . We show that R satisfies the defining properties of =
∼p , from which the result
will follow.
Reduction closure is straightforward, but let us look at the preservation of barbs.
Suppose J |= M R N , that is
Ih |= (new ẽ : D̃)(M | h
succ! V
) = 
∼p (new ẽ : D̃ )(N | h
succ! V
 (6.19)
and M ⇓barb J k.a. We have to show that N ⇓J barb k.a. We know J ≡ I , V :T
, and

if M ⇓I k.a, then this is straightforward. But it may be that a at k is not known

barb

in I ; if not we can still check that N can perform an output on a at k, by examining

the data produced at succ@h.
Let h be a fresh name, and let Ih,h be the extension of Ih by the declaration

h : loc[succ : T]. We know that a@k occurs somewhere in V :T
; let x@z be the
corresponding sub-pattern in X , and now consider the following code, B, designed
to run at h, which tests the data matching the sub-pattern x@z and produces a barb
at succ@h only if this is the required a@k:
succ?(X ) goto z.if z = k then (if x = a then x?(Y ) goto h .succ! X
else 0)
else 0
 6.7 Justifying bisimulation equivalence contextually in aDpi 239

It is easy to see that Ih,h h B and therefore by pcontextuality

Ih,h |= (new ẽ : D̃)(M | h
succ! V

) | h
B
= 
∼p (new ẽ : D̃ )(N | h
succ! V
) | h
B
Because of the design of B, one can check that

((new ẽ : D̃)(M | h
succ! V
) | h
B) ⇓barb
Ih,h h .succ

and since =
∼p preserves barbs we have

((new ẽ : D̃ )(N | h
succ! V
) | h
B) ⇓barb
Ih,h h .succ

But, again because of the design of B, this can only happen if M can produce an
output on a at k, that is M ⇓barb
J k.a.
So let us turn our attention to proving that R is pcontextual. First let us consider
(fresh location weakening). Suppose J |= M R N . We have to show
J , l:L
|= M R N (6.20)
for some l fresh to J ; it is convenient to pick one different from the special name
h. This assumption enables us to assert that
(I , l:L
)h ≡ Ih , l:L

But we know, from Question 10 at the end of the chapter, that =

∼p is by preserved
by weakening with respect to any fresh location; by applying this to (ii) we obtain
(I , l:L
)h |= (new ẽ : D̃)(M | h
succ! V
) = 
∼p (new ẽ : D̃ )(N | h
succ! V
)
From (i) we can also show J , l:L
≡ (I , l:L
), V :T
, which by the definition of
R gives the required (6.20).
Now let us consider (parallel). From J |= M R N we have to establish
J |= k
P  | M R k
P  | N
whenever J  k
P .
We know J ≡ I , V :T
, and
Ih |= (new ẽ : D̃)(M | h
succ! V
) = 
∼p (new ẽ : D̃ )(N | h
succ! V
) (6.21)
and we will show that
Ih |= (new ẽ : D̃)(M | k
P  | h
succ! V
) = 
∼p (new ẽ : D̃ )
(N | k
P  | h
succ! V
) (6.22)
for some fresh h . The hypothesis also says that
I , V :T
 k
P  (6.23)
240 Behavioural equivalences for aDpi

and so in (6.22) k
P  may use the data V to interact with M and N , although
the hypothesis (6.21) a priori does not compare the behaviour of M and N in the
presence of the knowledge of V . But this knowledge is available on succ at h. We
proceed as in the untyped version of the extrusion lemma, Lemma 2.38. Let Fhk
denote the following system, which delivers the value V from h to the site k:

h
succ?(X ) (goto k.PX | goto h .succ! X

)

where X is a pattern that matches V and PX is designed so that PX {|V/X |} behaves

just like P running at k. Unfortunately the design of PX is not completely
straightforward. There may be more than one variable in the pattern X that
is matched to a given name; and the capabilities used by a name in P may
partially come from I , and partially from V :T
. For these reasons, when defining
PX we need to repeatedly use the construct if v1 = v2 then . . . else 0 in
order to collect these dispersed capabilities. For example if I consists of k :
loc, b@k : r A
then I , b@k:w A
@loc
k P where P denotes (new a : A) b! a
|
b?(x) 0, and a required PX , such that I , x@z:r A
@loc
k PX , is (new a : A)
if k = z then x! a
| b?(y) else 0.
In this fashion, because I , V :T
is a standard extension, we can design PX so
that

(a) I, X :T
k PX
(b) I, V :T
|= P ≈bis PX {|V/X |}.

In (a) the use of the typing rule (ty-match) is essential, as we have just explained.
The term PX {|V/X |} does not correspond precisely with P, because of the required
insertions of matchings. But (b) follows because the behaviour of PX {|V/X |} does
mimic that of P precisely except that periodically it has to perform some β-moves
of the form if n = n then Q else 0 −→ Q.
From (a) above it is now straightforward to see that Ih  Fhk and so we can
apply pcontextuality to (6.21) to obtain

Ih,h |= (new ẽ : D̃)(M | h
succ! V

) | Fhk
=
∼p
(new ẽ : D̃ )(N | h
succ! V
) | Fhk

Since =∼p is preserved by (environment strengthening), from Question 11, the same
identity is also true for the more restricted environment Ih .
Now it is a simple matter of rewriting these system terms in a semantics preserving
manner, to obtain the required result. Exhibiting an explicit bisimulation-up-to-β
 6.7 Justifying bisimulation equivalence contextually in aDpi 241

moves we can show

Ih |= (new ẽ : D̃)(M | h
succ! V
) | Fhk
≈bis
(new ẽ : D̃)(M | k
P  | h
succ! V
)

Note that this is true because the location h is not available to the environment; it
does not occur in Ih . Since I |= M1 ≈bis M2 implies I |= M1 = ∼p M2 , the required
(6.22) follows, since the same identity holds for N .

These two proofs enable us to derive the essential result:

Corollary 6.39 Suppose that both I  M and I  N are strict configurations. Then
I |= M =∼ N implies I |= M ≈a N .
Proof: We show that the more restricted relation = ∼p , viewed as a relation over
strict configurations, is an asynchronous bisimulation. The result will then follow,
as I |= M = ∼ N obviously implies I |= Mµ = ∼p N .
So suppose I |= M = ∼p N and I  M −→ a M . We have to find a corresponding
µ̂ 
move I  N =⇒a N , such that
(I after µ) |= M  = ∼p N

(6.24)
In fact we do the matching up to structural equivalence.
If µ is the internal action τ , then this follows immediately, since by definition
=
∼p is reduction closed; note that here we are implicitly using the coincidence of
reduction with τ -moves, up to structural induction. So suppose µ is an external
α 
action α, of the form (ẽ : D̃)k.a!V or (ẽ : D̃)k.a?V . Then I  M −→ a M ensures,
by definability (Theorem 6.36), that
T (α) | M −→∗ (new ẽ : D̃)(h
succ! vI (α)
 | M  ) (6.25)
Since =
∼p is closed with respect to arbitrary fresh location weakening, we have
Ih |= M = ∼p N
The definability result also ensures that Ih  T (α). So the pcontextuality of =
∼p
(and the particular form of the actual system T (α)) ensures that
Ih |= T (α) | M =
∼p T (α) | N
At this stage the fact that =
∼p is reduction-closed ensures that (6.25) must be
matched by some reduction
T (α) | N −→∗ R
242 Behavioural equivalences for aDpi

where

Ih |= R =∼p (new ẽ : D̃)(h
succ! vI (α)
 | M )
But =∼p also preserves barbs and so we must have R ⇓
barb h.succ and R  ⇓barb

h.fail. So applying definability again we know that R must be structurally equivalent

to a system of the form (new ẽ : D̃ )(h
succ! vI (α)
 | N  ), for some N  such that

I  N =α⇒a N  , for some α  ∼ α.
Now we can apply extrusion, Lemma 6.38, to obtain
I , vI (α):tyI (α)
|= M  =
∼p N

(6.26)
But this is enough to establish (6.24) above as I , vI (α):tyI (α)
is by definition
I after α.

This concludes our exposition of the theory underlying contextual equivalences

for aDpi. The results may be summarised as follows:
Theorem 6.40 (full-abstraction) Suppose   M , N . Then
•  |= M ≈bis N implies  |= M = N
∼
•  |= M ≈a N if and only if  |= M = N .

∼

6.8 Questions
µ
1. Suppose I  M −→ I   M  .
(i) If µ is the input label (ẽ : D̃)k.a?V , prove
• each ei appears in the domain of V :I w (a@k)
@k
• fn(M  ) ⊆ fn(M ) ∪ n(V ).
(ii) If µ is the output label (ẽ : D̃)k.a!V , prove
• each ei appears in the domain of V :I r (a@k)
@k
• fn(M  ) ⊆ fn(M ) ∪ bn(ẽ)
• n(V ) ⊆ fn(M ) ∪ bn(ẽ).
(iii) If µ is τ then fn(M  ) ⊆ fn(M ).
µ
2. Suppose I  M −→ I   M  , where µ is the label (c@l : C)k.a!c. Show that l and k
must coincide.
3. Use Question 5 from Chapter 5 to prove that whenever the rule (l-out) is applied to a
valid configuration, the result, I V :I r (a@k)
@k k
stop, is also a valid configuration.
µ
4. (Weakening) Suppose I  M −→ M  is an action-in-context for aDpi. Let Im  M be
µ
a configuration such that Im <: I. Prove that Im  M −→ M  is also a valid action-in-
context.
(See Lemma 4.11.)
5. (Fresh strengthening). State and prove a suitable generalisation of (fresh strengthening)
from Lemma 4.11 to the actions in context of aDpi.
 6.8 Questions 243

6. Prove that ≈a , viewed as a typed relation is contextual. That is

(i) I |= M ≈a N and I  O implies I |= M | O ≈a N | O and I |= O | M ≈a O | M
(ii) I, e:D
|= M ≈a N implies I |= (new e : D) M ≈a (new e : D) N
(iii) if I  (new e : D) M and I  (new e : D) N are both valid configurations, then
I, e:D
|= M R N implies I |= (new e : D) M R (new e : D) N .
7. (i) Referring to Example 6.26, prove Ia |= k
a?a! ≈a k
stop.
(ii) Without using the completeness theorem, Theorem 6.40, prove Ia |= k
a?a! = ∼
k
stop.
8. Let ≡p be the least contextual equivalence relation between aDpi processes that satisfies
the appropriate typed version of the axioms in Figure 2.3. Suppose P ≡p Q. Prove
(i)   k[P] if and only if   k[Q].
(ii) P ≡p Q implies  |= k[P] ≈bis k[Q] for any  such that   k[P].
9. Prove the assertion (6.18) from Example 6.31.
10. See Question 10 in Chapter 2 for the definition of when a name substitution σ is injective
for a set of names.
• Suppose σ is injective for all (simple) names used in I, M , N . Prove I |= M = N
∼
implies Iσ |= M σ = ∼ Nσ.
• Show that the same property holds for =p .
∼
• Use this to show that =p is preserved by arbitrary fresh location weakening; that is
∼
I |= M = ∼p N implies I, l:L
|= M =∼p N for any l fresh to I.
11. Prove that both =
∼ and =∼p are closed under environment strengthening; that is I |=
M= ∼p N and I <: Il implies Il |= M =
∼p N .
 Sources

Chapter 1: Proofs by induction permeate the theoretical foundations of computer

science; [41] is a particularly good source, oriented towards computer scientists.
The standard reference for bisimulation theory is [28], although the first part of [29]
also covers much of this material. References to a number of introductory papers
may be found at the website http://lampwww.epfl.ch/mobility/.
Chapter 2: The pi-calculus has its origin in the label passing calculus of [9]; see
[10] for a more recent perspective on this work. This led to the actual development
of the pi-calculus, reported originally in [30, 31]. However [29] is an excellent
introduction, while [39] is now the standard, and encyclopaedic, reference text.
When consulting the large research literature on the pi-calculus, the reader
should bear in mind that there is considerable variation in the actual syntax used.
For example there may be no distinction made between names and variables,
the match operator if v1 = v2 then R1 else R2 may be absent, or may be replaced
by a partial operator if v1 = v2 then R, and instead of the recursion operator
rec x. R there may be an iteration operator !P, or some mechanism for defining
constants using recursive definitions.
The version of the pi-calculus presented in Chapter 2 is usually referred to as the
asynchronous pi-calculus. It was originally proposed in [5], and independently
in [20, 21], as a simplified language, in which the output action of the original
language, c! V
.P, is replaced by c! V
; see Question 13 at the end of Chapter 2.
Our asynchronous lts semantics, in Figure 2.6 and Figure 2.5, is based on the theory
developed in [21, 19]. An alternative lts semantics is used in [40], which is based
on [2]; see Question 16 at the end of Chapter 2.
Our touchstone behavioural equivalence, reduction barbed congruence
Definition 2.25, is taken from [21]. A variation, called barbed congruence was
proposed in [32], and is used extensively in [39]. Briefly barbed bisimilarity is first
defined as the largest relation that is reduction-closed and preserves observations.

244
 Sources 245

Then barbed congruence is defined to be the largest contextual relation contained

in barbed bisimilarity. In contrast our relation, reduction barbed congruence, is
simply taken to be the largest one satisfying all three properties simultaneously.
It is difficult to give rational arguments as to why one of these relations is more
reasonable than the other. We have chosen reduction barbed congruence because it
has a simpler definition – we want a behavioural equivalence that has such and such
properties, and nothing more – and it is marginally more easy to apply technically.
Chapter 3:An excellent introduction to the theory of types is given in [36], although
it is oriented towards their application in sequential programming languages. The
first system of types for the pi-calculus appeared in [33], where it was called
a sorting system. This is more or less equivalent to our simple types, discussed
in Sections 3.1 and 3.2, augmented by a mechanism for defining recursive types.
Type systems with separate input and output capabilities on channels were first
introduced in [34], although our version, in Section 3.4, is based on [16]. The latter
is more general in that it allows types of the form rw Tr , Tw
, where the types at
which values can be read and written, Tr and Tr , need not be the same; in the former
these types must be identical. This restricted set of types is not in general partially
complete, see Question 13, a property that we use extensively. This idea of allowing
different read and write capabilities in channel types was originally introduced in
[18].
Part III of [39] discusses numerous other type systems for the pi-calculus, and
variations thereof.
Chapter 4: The first treatment of the effect of types on behavioural equivalences
appeared in [34], and this line of research was further developed in [35] and [24];
it is discussed at length in Part IV of [39]. Our treatment is simply a variation on
this, using the more general capability types. It is based entirely on [16], although
there are some technical differences in both the set of types used, and some of the
typing rules.
Chapter 5: aDpi is the asynchronous version of the language Dπ originally
presented in [18]. The type system for aDpi is also taken from there; it is essentially
the type system given in section 5 of that paper. The registered resource types rc C

discussed in Section 5.5 were first introduced in [15]. The approach to type safety
for aDpi, in Section 5.4, using tagged agents, is also taken directly from [18]. An
alternative approach, in which occurrences of resource names are tagged, was given
in [34], and is reported in [39].
Work on aDpi has been developed further in various directions. As presented
in Chapter 5, the control of behaviour offered by types depends on a global type
environment, and the assurance that all players in a system are well-typed. This is
246 Sources

relaxed in [37], where each domain maintains its own type environment, recording
its current knowledge of the network; this is periodically updated, with the arrival
of new agents. A notion of trust is added to the type of domains, and it is shown
how dynamic typing can protect trusted sites from untyped agents. In [17] aDpi
is extended with the ability to transfer parameterised higher-order code between
domains, which can be instantiated with local parameters by the receiving site.
Within this framework both host and agent security can be maintained by the
use of dependent and existential types. Finally in [23] recursive types have been
added; to appreciate the usefulness of recursive types see Question 4 at the end of
Chapter 5.
Chapter 6: The behavioural theory was originally presented in [15], while the
example proofs come from [1]. This behavioural theory, parameterised with respect
to type environments, should be widely applicable. For example, it has been
extended to the higher-order version of aDpi, already referred to above, in [17].
Finally in [11] it has been extended to a version of the language in which locations,
and the connectivity links between them, may fail.
General methods for reducing the size of witness bisimulation relations were
studied in [38] for CCS and the pi-calculus, and are reported in [39]. Many
of these transfer to aDpi, but care must be taken in the presence of types. Our
technique based on β-moves, in Section 6.3, was influenced by [25], although
similar techniques are widely used in the literature; see for example [14, 13].
aDpi represents only one of the many attempts to add notions of location
or domain to the pi-calculus. The website http://lampwww.epfl.ch/
mobility/ maintains an up-to-date account of research activities in the area.
Here we mention only briefly a sample of the more obviously related approaches.
Nomadic Pict [42, 40] is conceptually closely related to aDpi, in that the space of
domains is flat, and agents migrate between these domains of their own volition.
However, unlike aDpi, agents are explicitly named and these names are used in
inter-agent communication. Nevertheless all communication is still channel-based
and local to particular domains.
On the other hand in Klaim [3, 4], communication is global, in the sense
that agents at different domains may nevertheless communicate. In addition
the underlying communication mechanism is quite different from that in aDpi.
Here every domain maintains a data-set, often called a tuple-space and agents
communicate indirectly by performing a set of pre-defined look-up and update
operations on these spaces.
In the Seal calculus [8], domains are hierarchically organised computational sites
in which inter-seal communication, which is channel-based, is only allowed among
siblings, or between parents and siblings. Seals themselves may be communicated;
 Sources 247

in effect this represents a sophisticated form of higher-order communication, in

which active code is transmitted between domains.
Finally Ambients [7, 6, 27] is radically different from aDpi. Here domains, called
ambients, are hierarchically nested as in the Seal calculus; but in ambients the
notion of process as we have been using it more or less disappears. Instead these
domains play the primary computational role. In fact computations consist solely of
movements of these domains, in or out of their parent domain, or sibling domains.
Then more standard notions of communication, such as the local communication
channels, are implemented in terms of these mobile domains.
 List of figures

1.1 Syntax for finite machines 2

1.2 An inductive definition of actions 2
2.1 Syntax for aPi 11
2.2 Patterns and values in aPi 11
2.3 Structural equivalence for aPi 17
2.4 Reduction semantics for aPi 18
2.5 An action semantics for aPi 28
2.6 Asynchronous input rules for aPi 44
3.1 Runtime errors in aPi 57
3.2 Simple types for aPi 58
3.3 Simple type environments for aPi 59
3.4 Typing values in aPi 60
3.5 Inference of simple types in aPi 62
3.6 Capability types for aPi – informal 75
3.7 Subtyping for aPi 75
3.8 Capability type environment for aPi 79
3.9 Typing values with capability types aPi 80
3.10 Inference of capability types in aPi 81
4.1 External actions-in-context for typed aPi 100
4.2 Internal actions-in-context for typed aPi 101
5.1 A distributed system 125
5.2 Syntax for aDpi 128
5.3 Patterns and values in aDpi 129
5.4 Reduction semantics for aDpi 131
5.5 Structural equivalence for aDpi 133
5.6 Types for aDpi – informal 140
5.7 Subtyping for aDpi 141

248
 List of figures 249

5.8 Type environments in aDpi 144

5.9 Typing values in aDpi 144
5.10 Typing systems 145
5.11 Typing agents 149
5.12 Runtime errors in aDpi 170
5.13 Tagged aDpi 173
5.14 Runtime errors in tagged-aDpi 180
5.15 Types for registered resource names 187
5.16 Typing with registered resource names 189
6.1 External actions-in-context for aDpi 197
6.2 Internal actions-in-context for aDpi 198
6.3 Asynchronous actions-in-context for aDpi 231
 Notation

Meta-variables:
n, m, a, b, c, l, k Names
x, y, z Vars
bv basic values, integers, etc. Figure 2.2
u, w identifiers, Names ∪ Vars
v simple values Figure 2.2
V values, (v1 , . . . , vn ) Figure 2.2, Figure 5.3
e compound values Figure 5.3
R, S, B terms in aPi Figure 2.1
agent terms in aDpi Figure 5.2
P, Q processes, closed terms in aPi Notation 2.1
agents, closed process terms
in aDpi page 131
M , N, O systems in aDpi Figure 5.2
Mt , Nt tagged systems in tagged-aDpi Figure 5.13
µ, α, αo , αi , τ action labels aPi page 27
typed aPi page 99
T transmission types aDpi page 195
typed aPi Figure 3.2,
Figure 3.6
aDpi Figure 5.6
A value types typed aPi Figure 3.2,
Figure 3.6
aDpi Figure 5.6
C channel types in typed aPi Figure 3.2, Figure 3.6
local channel types in aDpi Figure 5.6

250
 Notation 251

D declaration types typed aPi Figure 3.2,

Figure 3.6
aDpi Figure 5.6
E (environment) entry types typed aPi page 59
aDpi page 143
, , I type environments typed aPi page 59
aDpi page 143
aDpi with registered
channels page 187

Types
a↓b {a, b} has a lower bound Definition 3.19
a↑b {a, b} has an upper bound Definition 3.19
S↓ page 77
T1 ↓ T2 aPi Proposition 3.20
aDpi Proposition 5.9
a  b, a  b lower/upper bounds Definition 3.19
T 1  T2 , T 1  T 2 aPi Proposition 3.20
aDpi Proposition 5.9
tyI (α) aDpi page 236
vI (α) aDpi page 236

Type environments
V :T aPi Definition 3.2
V :T@k aDpi Definition 5.12
e:T aDpi page 146
I after µ aPi Definition 4.6
aDpi Notation 6.2
I allows µ aPi Definition 4.9
aDpi Notation 6.2
(u),  r (u),  w (u), (u)↓def aPi Definition 3.25
(e),  r (e),  w (e), (e)↓def aDpi Definition 5.22
1 <: 2 , 1 ≡ 2 aPi Definition 3.27
page 88
aDpi Definition 5.24
aDpi with registered
names Definition 5.55
252 Notation

↓u : E aPi page 79, also used for

aDpi
 ↓w u : E aDpi Definition 5.10
{u} aPi page 86
{e} aDpi page 160

Typing:
T <: U typed aPi Figure 3.7
aDpi Figure 5.7
 T <: U aDpi with registered
names Figure 5.15
sT : ty aPi Notation 3.1
T : ty aPi Definition 3.16
aDpi Definition 5.8
 rc T : ty aDpi page 187
 s env typed aPi Figure 3.3
 env typed aPi Figure 3.8
aDpi Figure 5.8
aDpi with registered
resources Figure 5.15
 s V :T typed aPi Figure 3.4
 V :T typed aPi Figure 3.9
 w V : T aDpi Figure 5.9
 s R : proc typed aPi Figure 3.5
 R : proc typed aPi Figure 3.10
 w R : proc aDpi Figure 5.11
 s M aDpi Figure 5.10

Operational semantics:
P≡Q structural equivalence aPi Figure 2.3
M ≡N aDpi Figure 5.5
Mt ≡ Nt tagged-aDpi Figure 5.13
P −→ Q reduction semantics aPi Figure 2.4
M −→ N aDpi Figure 5.4
Mt −→t Nt tagged-aDpi Figure 5.13
P −→err runtime errors aPi Figure 3.1
M −→err
 aDpi Figure 5.12
Mt −→err tagged-aDpi Figure 5.14
 Notation 253

P ⇓barb c observations aPi Definition 2.22

M ⇓barb
I k.c aDpi Definition 6.20
µ
P −→ Q actions aPi Figure 2.5
µ
I  P −→ I Q actions-in-context typed aPi Figure 4.1,
Figure 4.2
µ
I  P −→ Q shorthand, Notation 4.8
µ
P −→ Q shorthand, Notation 4.8
µ
I  M −→ I  N aDpi Figure 6.1, Figure 6.2
µ
I  M −→ N shorthand page 199
µ
M −→ N shorthand, Notation 6.2
µ
I  M −→ a I N asynchronous aDpi Figure 6.3
actions-in-context
I  M −τ→
β
N β-moves aDpi page 203

Semantic equivalences
un(µ) output type omission aPi page 113
aDpi page 199
µ ∼ µ action equivalence aPi page 199
aDpi page 199

P ∼bis Q strong bisimulation equivalence page 5

P ≈bis Q bisimulation equivalence Definition 1.5, Definition 1.6
aPi page 34
P ≈a Q asynchronous bisimulation aPi Definition 2.31
equivalence
P=∼Q reduction barbed congruence aPi Definition 2.25
I |= P ≈bis Q typed bisimulation equivalence aPi page 114
I |= M ≈bis N aDpi page 201
I |= M ≈a N typed asynchronous bisimulation aDpi Definition 6.28
I |= M =
∼N typed reduction barbed congruence aDpi Definition 6.23
 Bibliography

[1] Julian Rathke, Alberto Ciaffaglione, and Matthew Hennessy. Proof methodologies
for behavioural equivalence in distributed pi-calculus. Computer Science Report
3:2005, University of Sussex, 2005.
[2] R. Amadio, I. Castellani, and D. Sangiorgi. On bisimulations for the asynchronous
π -calculus. Theoretical Computer Science, 195:291–324, 1998.
[3] Lorenzo Bettini, Viviana Bono, Rocco De Nicola, Gian Luigi Ferrari, Daniele Gorla,
Michele Loreti, Eugenio Moggi, Rosario Pugliese, Emilio Tuosto, and Betti Venneri.
The klaim project: Theory and practice. In Corrado Priami, ed., Global Computing,
volume 2874 of Lecture Notes in Computer Science, pp. 88–150. Springer, 2003.
[4] Lorenzo Bettini and Rocco De Nicola. Mobile distributed programming in x-klaim.
In Marco Bernardo and Alessandro Bogliolo, eds, SFM, volume 3465 of Lecture
Notes in Computer Science, pp. 29–68. Springer, 2005.
[5] G. Boudol. Asynchrony and the π-calculus. Technical Report 1702, INRIA-Sophia
Antipolis, 1992.
[6] Luca Cardelli and Andrew D. Gordon. Types for mobile ambients. In POPL ’99:
Proceedings of the 26th ACM SIGPLAN-SIGACT symposium on principles of
programming languages, pp. 79–92, New York, NY, USA, 1999. ACM Press.
[7] Luca Cardelli and Andrew D. Gordon. Mobile ambients. Theoretical Computer
Science, 240(1):177–213, 2000.
[8] G. Castagna, J. Vitek, and F. Zappa Nardelli. The seal calculus. Information and
Computation, 201(1):1–54, 2005.
[9] U. Engberg and M. Nielsen. A calculus of communicating systems with
label-passing. Technical Report, Arhus University, 1986.
[10] Uffe H. Engberg and Mogens Nielsen. A calculus of communicating systems with
label passing-ten years after. In Gordon Plotkin, Colin Stirling and Mads Tofte, eds,
Proof, Language, and Interaction; Essays in Honour of Robin Milner, Foundations
of Computing, chapter V, Mobility, pp. 599–622. MIT Press, 2000.
[11] Adrian Francalanza and Matthew Hennessy. A theory of system behaviour in the
presence of node and link failures. In Conference on Concurrency Theory,
pp. 368–382, 2005.
[12] A.D. Gordon and A.S.A. Jeffrey. Types and effects for asymmetric cryptographic
protocols. Journal of Computer Security, 12(3/4):435–484, 2004.

254
 Bibliography 255

[13] J.F. Groote and M.P.A. Sellink. Confluence for process verification. Theoretical
Computer Science, 170(1–2):47–81, 1996.
[14] Jan Friso Groote and Jaco van de Pol. State space reduction using partial
tau-confluence. In Mathematical Foundations of Computer Science, pp. 383–393,
2000.
[15] Matthew Hennessy, Massimo Merro, and Julian Rathke. Towards a behavioural
theory of access and mobility control in distributed systems. Theoretical Computer
Science, 322:615–669, 2003.
[16] Matthew Hennessy and Julian Rathke. Typed behavioural equivalences for processes
in the presence of subtyping. Mathematical Structures in Computer Science,
14:651–684, 2004.
[17] Matthew Hennessy, Julian Rathke, and Nobuko Yoshida. Safedpi: A language for
controlling mobile code. Acta Informatica, 42(4-5):227–290, 2005.
[18] Matthew Hennessy and James Riely. Resource access control in systems of mobile
agents. Information and Computation, 173:82–120, 2002.
[19] K. Honda and N. Yoshida. On reduction-based process semantics. Theoretical
Computer Science, 152(2):437–486, 1995.
[20] Kohei Honda and Mario Tokoro. An object calculus for asynchronous
communication. In ECOOP ’91: Proceedings of the European Conference on
Object-Oriented Programming, pp. 133–147, London, UK, 1991. Springer-Verlag.
[21] Kohei Honda and Mario Tokoro. On asynchronous communication semantics. In
P. Wegner, M. Tokoro, and O. Nierstrasz, eds, Proceedings of the ECOOP ’91
Workshop on Object-Based Concurrent Computing, volume 612 of LNCS 612.
Springer-Verlag, 1992.
[22] Kohei Honda and Nobuko Yoshida. A uniform type structure for secure information
flow. In Symposium on Principles of Programming Languages, pp. 81–92, 2002.
[23] Samuel Hym and Matthew Hennessy. Adding recursion to dpi. In Peter D. Mosses
and Irek Ulidowski, eds, Preliminary Proceedings of the Second Workshop on
Structural Operational Semantics, pp. 50–67, 2005. Full version available as
Computer Science Report 2005:06, University of Sussex.
[24] A.S.A. Jeffrey and J. Rathke. Full abstraction for polymorphic pi-calculus. In
Proceedings of Foundations of Software Science and Computation Structures,
volume 3441 of Lecture Notes in Computer Science, pp. 266–281. Springer-Verlag,
2005.
[25] Alan Jeffrey and Julian Rathke. A theory of bisimulation for a fragment of
concurrent ml with local names. Theoretical Computer Science, 323:1–48, 2004.
[26] Naoki Kobayashi. Type systems for concurrent processes: From deadlock-freedom
to livelock-freedom, time-boundedness. In Jan van Leeuwen, Osamu Watanabe,
Masami Hagiya, Peter D. Mosses, and Takayasu Ito, eds, IFIP TCS, volume 1872 of
Lecture Notes in Computer Science, pp. 365–389. Springer, 2000.
[27] Massimo Merro and Francesco Zappa Nardelli. Behavioural theory for mobile
ambients. In Jean-Jacques Lévy, Ernst W. Mayr, and John C. Mitchell, eds, IFIP
TCS, pp. 549–562. Kluwer, 2004.
[28] R. Milner. Communication and Concurrency. Prentice-Hall, 1989.
[29] R. Milner. Comunicating and mobile systems: the π -calculus. Cambridge University
Press, 1999.
[30] R. Milner, J. Parrow, and D. Walker. A calculus of mobile processes, Part I.
Information and Computation, 100(1):1–40, 1992.
256 Bibliography

[31] R. Milner, J. Parrow, and D. Walker. A calculus of mobile processes, Part II.
Information and Computation, 100(1):41–77, 1992.
[32] R. Milner and D. Sangiorgi. Barbed bisimulation. In W. Kuich, ed., Proceedings
19th ICALP, volume 623 of Lecture Notes in Computer Science, pp. 685–695.
Springer-Verlag, 1992.
[33] Robin Milner. The polyadic π-calculus: a tutorial. In Proceedings International
Summer School on Logic and Algebra of Specification, Marktoberdorf, 1991.
[34] B. Pierce and D. Sangiorgi. Typing and subtyping for mobile processes. Journal of
Mathematical Structures in Computer Science, 6(5):409–454, 1996. An extended
abstract in Proceedings LICS 93, IEEE Computer Society Press.
[35] B. Pierce and D. Sangiorgi. Behavioral equivalence in the polymorphic pi-calculus.
Journal of the ACM, 47(3):531–584, 2000.
[36] B.C. Pierce. Types and programming languages. The MIT Press, 2002.
[37] James Riely and Matthew Hennessy. Trust and partial typing in open systems of
mobile agents. Journal of Automated Reasoning, 31:335–370, 2003.
[38] D. Sangiorgi. On the bisimulation proof method. Mathematical Structures in
Computer Science, 8:447–479, 1998.
[39] D. Sangiorgi and D. Walker. The π -calculus: a Theory of Mobile Processes.
Cambridge University Press, 2001.
[40] Peter Sewell, Paweł T. Wojciechowski, and Benjamin C. Pierce.
Location-independent communication for mobile agents: a two-level architecture. In
Internet Programming Languages, LNCS 1686, pp. 1–31. Springer-Verlag, October
1999.
[41] G. Winskel. The Formal Semantics of Programming Languages. The MIT Press,
1992.
[42] Paweł T. Wojciechowski and Peter Sewell. Nomadic Pict: Language and
infrastructure design for mobile agents. In Proceedings of ASA/MA 99: Agent
Systems and Applications/Mobile Agents (Palm Springs), pp. 2–12, October 1999.
 Index

α-conversion, 69 bisimulation equivalence, 42, 208

α-equivalence, 15, 29, 63 asynchronous, 46, 51, 232
β-commutativity, 204 for aDpi, 200
β-move, 203, 207 for aPi, 34
β-transfer property, 209, 212 for typed aPi, 114
strong, 5
bound name, 14, 130, 133
action bound variable, 14
asynchronous, 44
for aPi, 27 capability, 55, 72, 125, 148
residual, 2 channel type, 72
weak, 7 closed term, 14
action definability co-variance, 92
for aDpi, 236 co-variant, 75
for aPi, 48 coinduction, 6
action label compositionality, 96, 117, 118, 201, 224
for aDpi, 195, 200 compositionality principle, 96
for aPi, 236 compound name, 126
for typed aPi, 99 compound value, 132
action residual, 27, 103, 198 computation, 21
actions, 27 configurations, 4, 109, 111, 195, 199
actions-in-context, 195 for aPi, 99
asynchronous, 230 strict, 234, 236, 241
distributed, 195 consistent types, 77
for aPi, 99 contexts, 17
untyped, 113 contextual, 16, 17, 19, 32, 35, 41, 47, 52, 56, 131, 179,
agent, 126, 129, 131, 134, 148, 177 227, 229
algebraic laws, 202 contextual equivalence, 37, 41
arity of values, 11 contra-variance, 81, 91
asynchronous, 12, 45 contra-variant, 75
input, 44
lts, 45
definability, 236
determinacy, 104, 199
Barendregt convention, 15 distributed consistency, 185
bisimulation, 7 domain, 124
asynchronous, 45
equivalence, 7 environments, 88
simple, 8 comparison of, 191
strong, 4 type, 58
up to structural induction, 115 equivalence, structural, 17
up to structural equivalence, 35 equivalent, 88
up-to-β, 209, 214, 217, 219, 224 extrusion, 238

257
258 Index

extrusion lemma process, 131

for aDpi, 238 recursive, 12
for aPi, 50
reduction, 131
reduction barbed congruence
for aDpi, 227
firewall, 221
for aPi, 41
free name, 14, 130, 133 reduction semantics, 30
free variable, 14 for aDpi, 131
fresh, 15, 29, 34, 50, 101, 195, 236, 238 for aPi, 16
full-abstraction for tagged aDpi, 174
for aDpi, 242 reduction-closed, 40
for aPi, 51 reduction-closure, 40, 227
registered resource names, 186
residual, 4
run-time error, 55, 71
identifiers, 10, 15 for aDpi, 170
induction, 1 for aPi, 57
rule, 3 for tagged aDpi, 179
structural, 2
interchange, 67, 69, 90 sanity check, 66, 106, 154
partial, 162 scope extrusion, 18, 20, 22, 133
stable state, 21
static analysis, 56
strengthening, 67, 70, 90, 116, 161, 201
knowledge environment, 98, 102 fresh, 106
structural equivalence, 31, 35, 127, 208
for aDpi, 133
for aPi, 17
labelled transition system, see lts for tagged aDpi, 175
local consistency, 143 subject reduction, 65, 207
local resources, 124, 151 for aDpi, 167, 199
for aPi, 91
lts
for registered resources, 191
asynchronous, 45, 232 for tagged-aDpi, 178
for aDpi, 200 for tagged-aPi, 107
for aPi, 34 simple types, 70
for typed aPi, 113 substitution, 14, 15, 68, 163, 165
lts semantics, 16 subsumption, 87, 160, 164, 168, 188
subtyping, 74, 78, 91
for aDpi, 141, 187
for aPi, 75
migration, 124, 128, 132, 135, 149 supertype, 74, 80, 126, 158, 222
mobile agent, see agent
tagged systems, 173
transfer property, 5, 7, 8, 40, 211
type
observations access control, 139
for aDpi, 226 capability, 75, 141
for aPi, 38 channel, 58
declaration, 57, 61
operational semantics, 4
environment, 58
global channel, 140
location, 125, 140, 187
local channel, 140
partial interchange, 162 object, 58
partially complete, 77 registration, 186
patterns, 11, 150 simple, 58
pcontextual, 237, 239, 241 transmission, 58, 126, 140, 197
 Index 259

type environment, 58 typechecking

comparison of, 88 for aDpi, 147
comparison of, 161 for aPi, 60, 80
constructing of, 62 for tagged aDpi, 176
construction of, 146 typed relation, 226
equivalence of, 88 typing system enforces, 151
for aDpi, 143
for aPi, 59, 79
type safety, 65, 170
for aDpi, 169
for aPi, 71 weakening, 67, 69, 88, 101, 161, 183, 188
for tagged-aDpi, 180 fresh, 116, 201