The purpose of this chapter is to caution the reader about straying from the templates given in Chapter 6; to explicitly state the semantic assumptions inherent in our basic PDL, and to highlight factors which must be checked when extending PDL or devising templates for target languages not mentioned in this text.

PDL is a very small language, having relatively few fundamental operations and processes. Moreover the semantics, the meanings, of these components relate directly and simply to corresponding features in implemented languages. Proper definition of programming language semantics is a non-trivial task and definitely far too involved to be adequately discussed here. However, since we want our programs to actually carry out computations, and not be purely static objects represented by symbols on paper or on a screen, we cannot totally avoid semantics; so what do we do?

Recall that an implementation of an operation is correct if all its required external characteristics are described by its specification. It would therefore be true to say that the semantics of the operation can be fully described/ defined by the inter-relationship between input/state and output/state of an appropriate specification. So what is the problem? The problem is that very few implementations of programming languages are defined adequately enough to enable us to use the definition in a formal way.

The nature of a specification

The task of solving a problem using a computer can be reduced to the outline

1. given THIS,

2. produce THAT

or expanding, a little,

1. given some DATA,

2. produce some RESULTS

3. which are the proper results for that data.

The results are either the ‘proper’ results for that data, or they are not. A specification can be viewed as a test that has been devised to check for ‘proper’ results. It does not need to show HOW the results are to be obtained although it may. Thus the task of solving a problem using a computer may be regarded in general as

1. given d,

2. produce r

3. such that S(d,r) is True

where S(d,r) is a test (or predicate) which, given the data d and the results r produced from it, delivers the answer True or False, i.e. the results are acceptable (or not) for that data.

Example

1. Let d be 169,

2. let r be 13

3. and suppose Sl(d,r) IS_DEFINED_TO_BEd=r⋆r.

(As is conventional in computing we are using ‘⋆’ to mean multiply. IS_DEFINED_TO_BE is an example of our use of a word or a phrase where a mathematical symbol would have been more concise. However we do not want unfamiliarity with symbols to prevent easy reading at this stage so we obtain clarity at the expense of brevity. The words in the phrases are always joined by underline and should be regarded as a single unit. In later chapters we will introduce the more concise notation.)

An appraisal of the current situation.

Is anything the matter?

In the early days of computing the machines were not very powerful, there were not many of them and few people had high expectations of them. All that has changed. Computers seem to have become an essential part of everyday society and large numbers of people are employed in supporting existing computer systems and creating new ones.

Although the use of computers is widespread the public image of computers and the computing profession is in need of improvement. Everyone has their own story to tell of the time when their enquiry was rejected with the excuse that ‘it's not possible since we installed the computer system’. There have been some well-publicised disasters with new computing systems.

Yes, something is the matter!

What is wrong with computing today?

Is it the machines? Well they are cheaper, smaller, faster and more reliable than they used to be. No, they do not seem to be the problem.

Is it the programs then? Software today is more expensive, more complex, but no more reliable than it used to be.

Why should this be? Is it the fault of the programmer teams? Are they not as clever as they used to be? No, they have been asked to do the impossible. It is like asking a child who has built toy houses out of Lego bricks to design and build tower blocks for people to live in.

The specification of functions and processes by means of pre-conditions and post-conditions requires that any repetitive or accumulative aspects of the computation must be indicated by recursion. Now, although many modern procedural programming languages support recursion and hence allow programming in a functional style, the run-time overhead of large amounts of stack manipulation imposed by the related control mechanism is unacceptable in certain applications.

Throughout this book, our central premise has been that to make best use of programmer efforts we should concentrate on correctness and ignore run-time efficiency considerations. Of course, to spend much time and effort developing a correct program only to have its correctness violated by the introduction of some slick trick which substantially reduces execution time – but does not quite always work – is to invalidate the whole exercise. Consequently all such transformations and optimisations must also be proven correct and, if appropriate, programmed into the system so as to protect them from human error.

As noted in Chapter 9 we already trust hardware extensions to the minimal set of arithmetic functions which, for instance, compute integer sums and products without recursive recourse to the increment and decrement instructions. On the software side, we showed in Chapter 7 how certain dataflow charts can be unwound into iterative control flowcharts.

The recursion-to-iteration transformation given in Chapter 7 is particularly useful in that it is widely applicable.

Topological sorting is a classical example in the study of data structures and is often included within introductory programming courses in Computer Science at tertiary level. We shall use the problem to illustrate how a well-defined (and hence mathematical but not necessarily numerical) problem can yield a specification which, after appropriate transformation, gives rise to non-recursive PDL code and subsequently to a procedural program in a high-level language.

Although programs in procedural language are in effect algorithms, recall that the aim of this text is not the development of algorithms per se; and hence the algorithm which emerges at the end of the chapter is a consequence of the way in which we transform the problem specification. Other transformations would imply different algorithms. No value judgements are offered as to the quality of the resultant algorithm but it must be said that many years of programming experience will have had some effect on the way that the specification has been interpreted and subsequently transformed.

Problem formulation

In mathematical terminology the problem may be stated as: To find a linear ordering which is consistent with a given (necessarily acyclic) binary relation on a finite set'. Now whilst this may be fine for a (modern) Mathematician and should also be intelligible to any Computer Scientist who has attended a discrete mathematics course as part of his studies, it does not immediately suggest how we might formulate a proper specification of the process in terms of the fundamental entities at our disposal.

This is an introductory textbook on denotational semantics intended for interested computer scientists, for undergraduates towards the end of their course and for postgraduates beginning theirs. The material has been used in a final-year undergraduate course at the University of Western Australia for some years. The objective is to introduce readers to the range of material, both mathematical and practical, in the subject so that they may carry out simple applications and understand more advanced material.

The mathematical foundations of denotational semantics are covered in sufficient detail to illustrate the fundamental problems in semantic theory that were solved by Scott. The section is self-contained but a background including a computer-science or mathematics course on discrete structures or algebra would be helpful. It can be skipped on a first reading or omitted by a reader prepared to take the foundations on trust.

The remainder of the book covers the use of denotational semantics to describe sequential programming languages. Knowledge of at least one high-level programming language, such as Ada, Algol, C, Modula, Pascal or PL 1, is essential. It is an advantage to be aware of the general features of several languages so as to realize the variety available. Familiarity with compilation, interpretation and functional programming is also a help.

A great deal of emphasis is placed on practical work. The usual notation of denotational semantics is akin to a powerful functional programming language.

Denotational semantics is a formal method for defining the semantics of programming languages. It is of interest to the language designer, compiler writer and programmer. These individuals have different criteria for judging such a method – it should be concise, unambiguous, open to mathematical analysis, mechanically checkable, executable and readable depending on your point of view. Denotational semantics cannot be all things to all people but it is one attempt to satisfy these various aims. It is a formal method because it is based on well-understood mathematical foundations and uses a rigorously defined notation or meta-language.

The complete definition of a programming language is divided into syntax, semantics and sometimes also pragmatics. Syntax defines the structure of legal sentences in the language. Semantics gives the meaning of these sentences. Pragmatics covers the use of an implementation of a language and will not be mentioned further.

In the case of syntax, context-free grammars expressed in Backus–Naur form (BNF) or in syntax diagrams have been of great benefit to computer scientists since Backus and Naur [44] formally specified the syntax of Algol-60. Now all programming languages have their syntax given in this way. The result has been ‘cleaner’ syntax, improved parsing methods, parser-generators and better language manuals. As yet no semantic formalism has achieved such popularity and the semantics of a new language is almost invariably given in natural language.

The typical problem facing a programmer is to write a program which will transform data satisfying some properties or assertions ‘P’ into results satisfying ‘Q’.