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.

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.

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.

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.

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 aDpi, in Section 2.5, namely the justification of our typed bisimulation equivalence for aDpi.

In this chapter we take our first proper steps with Haskell. We start by introducing the Hugs system and the standard prelude, then explain the notation for function application, develop our first Haskell script, and conclude by discussing a number of syntactic conventions concerning scripts.

The Hugs system

As we saw in the previous chapter, small Haskell programs can be executed by hand. In practice, however, we usually require a system that can execute programs automatically. In this book we use an interactive system called Hugs, which is the most widely used implementation of Haskell.

The interactive nature of Hugs makes it well suited for teaching and prototyping, and its performance is sufficient for most applications. However, if greater performance or a stand-alone executable version of a program is required, a number of compilers for Haskell are also available, of which the most widely used is the Glasgow Haskell Compiler. This compiler also has an interactive version that operates in a similar manner to Hugs, and can readily be used in its place for the purposes of this book.

The standard prelude

When the Hugs system is started it first loads a library file called Prelude.hs, and then displays a > prompt to indicate that the system is waiting for the user to enter an expression to be evaluated.