Informal Specification

Professor Higgins wants to set up a small database to keep track of which students are enrolled in his course on computational metaphysics. He asks his programmer, Eliza Doolittle, to write a program that will allow him or his secretary to

• add a student record to the database;

• determine whether a particular student is currently enrolled; and

• remove a student record from the database.

Students are to be identified by their student numbers.

Eliza considers the problem and points out that the specification is incomplete: what should happen if a student is “added” when he or she is already enrolled? Or if a student is “removed” when that student has not yet enrolled? Professor Higgins replies that he would never make such mistakes; however, because the system will also be used by his secretary, he agrees that such operations should produce appropriate warning messages to the user.

Eliza intends to structure the program as two modules: one to manage the data representation and the other to provide the user interface. She decides that it should not be the responsibility of the data-representation module itself to produce error messages to the user; the user-interface module should do this. But where should the errors be detected?

If the data-representation module is responsible for detecting errors, it would be necessary for the operations to return error flags or to raise exceptions, which would significantly complicate the interface between the modules.

This book was written to support a short course in the second or third year of an undergraduate computer science, software engineering, or software design program. The prerequisites are fairly modest: some programming experience (ideally in C or C++ or a related language such as JAVA) and some exposure to the most basic concepts of discrete mathematics (sets, functions, binary relations, sequences) and to the language of elementary logic (connectives and quantifiers). It is intended to be only an introduction to software specifications, not a systematic survey of requirements engineering, formal methods, compilers, or computation theory suitable for a senior or graduate-level course. A course based on this book would provide a good foundation for such courses but should not replace them.

The contents may be summarized briefly as follows:

• specification, verification, and development of simple algorithms using pre- and post-conditions and loop invariants;

• specification, verification, and development of simple data representations using abstract models and representation invariants; and

• specification and systematic development of recognizers for formal languages using regular expressions, grammars, and automata.

These techniques have been well studied and are sound and useful. They may be presented to and immediately used by undergraduate students on simple but nontrivial examples. They may be taught without requiring upper-level prerequisites or major investments of time to teach complex notations or computer-based tools. But such material is not often presented at this level, nor in this combination.

We now consider specification and construction techniques tailored to a particular application domain: code that is intended to test whether arbitrary input strings may be matched by a specific “pattern.” The pattern itself is essentially the specification for such a program, and a variety of specialized notations and implementation techniques have been developed to allow convenient expression and realization of such specifications. Although the methods are specialized to the application, the key principles of formal methods—distinguishing between specification and realization, adopting appropriate formalized notation for specifications, and using systematic or verifiable methods of program construction—are still relevant. Chapter 7 introduces the basic concepts, and Chapters 8 to 11 discuss various styles of pattern specification and how they may be systematically transformed and realized.

Additional Reading

Many books cover this material, usually from either a primarily theoretical perspective [HU79, MAK88, LP98] or a compiler-oriented one [ASU86]; [Gou88, AU92, HMU01] are closest to the approach adopted here.

It may not be possible to implement a specification. The requirements may be inconsistent, the specification may be meaningless or ill-defined, or, surprisingly, the function specified may not be computable. The concept of an incomputable function comes from computability theory, a branch of mathematical logic with particular relevance to computer science.

Chapter 12 introduces some of the key ideas of computability theory, both as motivation for subsequent study and to provide the background necessary to appreciate the significance of an incomputability claim. In particular, we will prove that some functions are not computable by any C program, explain why such problems are deemed to be algorithmically unsolvable, and list a number of unsolvable problems of practical importance involving context-free grammars.

Additional Reading

Good presentations of elementary computability theory may be found in [RS86, Sip97, Jon97, GH98, LP98, HMU01].

Case Study: Searching an Array

Professor Higgins wants his programmer, Eliza Doolittle, to write a code fragment that is to test for the presence or absence of a value x in an array A. Here is the intended application: A is to contain the student numbers of all the students currently enrolled in his course on computational metaphysics, and x might be the student number of a student who is trying to verify that he or she is properly registered.

Exercise 1.1 Before reading on, pretend that you are Eliza Doolittle and try to write the desired code. Also, try to write an application program that uses the code.

As you will quickly discover if you try to write the desired code, or to write a program to use it, the preceding paragraph is an inadequate specification. Here are some of the questions that must be answered before (or during) the development of the desired code or any associated applications.

1. What is the range of allowed subscript values for A, and what segment of the array should be searched?

2. What is the type of variable x (also, presumably, the component type of the array), and how should values of this type be compared?

3. How should the result be recorded?

4. Is the array segment sorted in, say, ascending order, to allow use of a more efficient search method?

5. […]

This chapter and the next present various interpretations of λ-calculus strategies into the π-calculus. All the interpretations have two common features:

• • Function application is translated as a form of parallel combination of two processes, the function and its argument, and β-reduction is modelled as an interaction between them.

• • The encoding of a λ-term is parametric over a name. This name is used by (the translation of) the λ-term to interact with the environment.

In Section 14.2.1 we observed that a redex of the λ-calculus gives rise to a private interaction between two terms. In contrast, a redex of the π-calculus is susceptible to interference from the environment. This interference is avoided if the name used by the two processes to communicate is private to them. Therefore, the appearance of a β-redex in a λ-term should correspond, in the π-calculus translation of that term, to the appearance of two processes that can communicate along a private name. We also observed in Section 14.2.1 that the β rule of the λ-calculus is strongly asymmetric. In all encodings, the λ-terms are mapped onto processes of the Asynchronous π-calculus, the asymmetry of whose communication rule reflects that of the λ-calculus.

A name parameter is needed in the π-calculus encodings of λ-terms for the following reason. Roughly speaking, in the λ-calculus, λ is the only port; a λ-term receives its argument at λ. In the π-calculus, there are many ports (the names), so one needs to specify at which port (the encoding of) a λ-term interacts with its environment.

15.1 Continuation Passing Style

The parameter of the π-calculus encoding of a function can also be thought of as a continuation. In functional languages, a continuation is a parameter of a function that represents the ‘rest’ of the computation. Functions taking continuations as arguments are called functions in Continuation Passing Style (briefly CPS functions), and have a special syntactic form: they terminate their computation by passing the result to the continuation. The continuation parameter may also be thought of as an address to which the result of the function is to be delivered.

Part I presented a main line in the theory of the π-calculus, examining processes and behavioural equivalence in some depth. Part II continues the study of the calculus.

Its first segment addresses two of the book's central concerns: how to use π-calculus, and the question of its expressiveness. These two concerns are intimately connected, since using the calculus involves expressing things in it. Among the things whose expression is explored are computational data: simple data such as numbers and strings, and complex data such as records, lists, and graphs. Representing data is an attractive first exercise in using π-calculus, because it is simple and yet allows many common idioms to be demonstrated. The activity has a similar flavour to expressing entities such as numbers and partial recursive functions as terms of λ-calculus. As we will see, however, there are many striking points of contrast. We show by example how values of arbitrary datatypes and operations on them can be expressed as name-passing processes, and how evaluation of data is captured by reduction of those processes.

The calculus of Part I is sometimes referred to as the monadic π-calculus, because an interaction involves the communication of a single name between processes. The representations of data as processes make use of two additions to the monadic calculus. The first is polyadicity: the passing of tuples of names in communications. Polyadicity is perhaps the simplest addition to the monadic calculus that retains names as the only atomic data. As we will see, however, polyadicity forces consideration of types, an issue that can be left aside in the monadic calculus. The second addition to the monadic calculus used in representing data is recursive definition of processes. Polyadicity and recursion can be convenient when using π-calculus. Anything that can be expressed with their help can also be expressed without it, however. To demonstrate some of the reasoning techniques developed in Part I in alliance with polyadicity and recursion, we give an extended worked example. It establishes the equivalence of two implementations of a priority-queue datatype.

This Part is concerned with the relationship between λ-calculus and π-calculus. The λ-calculus is the prototypical functional language. The λ-calculus talks about functions and their applicative behaviour. This contrasts with the π-calculus, which talks about processes and their interactive behaviour. Application is a special form of interaction, and therefore functions can be seen as a special kind of processes. In this Part we study how the functions of the λ-calculus (the computable functions) can be represented as π-calculus processes. The π-calculus semantics of a language induces a notion of equality on the terms of that language. We therefore also analyse the equality among functions that is induced by their representation as π-calculus processes.

A deep study of representations of functions as π-calculus processes is of interest for several reasons. From the π-calculus point of view, the representation is a significant test of expressiveness, and is helpful in getting deeper insight into the theory. From the λ-calculus point of view, the representation makes it possible to apply process-calculus techniques to λ-calculus, and also to analyse λ-terms in contexts that are not purely sequential. This study may be useful for providing a semantic foundation for languages having constructs for functions and for concurrency, and techniques for reasoning about them. (Behavioural equalities between functions preserved in sequential contexts may not be preserved in nonsequential contexts; we will see examples of this in Chapter 17.) The study may also be helpful in developing parallel implementations of functional languages and in the design of programming languages based on process calculi.

Structure of the Part The Part is composed of five chapters. The first, Chapter 14, is about the λ-calculus. The second, Chapter 15, is about the encoding of the untyped λ-calculus into π-calculus. Chapter 16 does the same for the typed λ-calculus. Chapters 17 and 18 are about the full-abstraction problem for the simplest of the π-calculus encodings, namely that of the untyped call-by-name λ-calculus. A more detailed summary follows.

In Section 14.1 we review the syntax and reduction rules of the untyped λ-calculus. In Section 14.2, we look at some properties of the λ-calculus that make it strikingly different from the π-calculus: sequentiality and confluence. We also touch on the differences and the similarities between the basic computational rules of the two calculi.

4.1 Distinctions

The π-calculus makes no syntactic distinction between instantiable names and non-instantiable names, that is, between variables and constants. Sometimes, however, it is desirable to treat certain names as constants, that is, as not subject to instantiation. More generally, it is sometimes useful to work in a setting where certain names cannot be instantiated to the same name. This more general case is no more difficult technically than treating names as constants. This section shows how to treat the more general case, by means of a family of behavioural equivalences indexed by certain binary relations, distinctions, on names.

Suppose we wish to model some system as a π-calculus process, and that to achieve this, it is convenient to regard two names, s and r, as constants. For example, suppose s is to signify send and r receive in a process such as

In order that the occurrences of s and r in a process not be open to instantiation when it is placed in a context C, the hole in C must not be underneath an input prefix that binds s or r. Let us call the contexts with this property the (s, r)-faithful contexts.

Now suppose that two π-calculus processes describe the system in question, and that we wish to compare them. Then we would like an equivalence, that treats s and r appropriately, in that it satisfies the preservation property: if and is an (s, r)-faithful context, then. What is a suitable choice for ?

It is easy to see that neither bisimilaritv nor full bisimilaritv will do. The former is too weak, because in general, does not imply if the hole in C occurs under any input prefix. And the latter is too strong, because it demands bisimilaritv in all contexts, not just the (s, r)-faithful contexts.

We therefore need something in between, indeed a new class of equivalences, to handle all varieties of faithfulness. Generalizing slightly from the motivating example, we introduce a family of equivalences each of which demands bisimi-laritv under all substitutions that maintain the distinction between certain pairs of names. Each member of the family is indexed by a relation that prescribes the relevant pairs.

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

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

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

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

2.1 Strong barbed congruence

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

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

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