Programming Language Semantics

David A. Schmidt
Department of Computing and Information Sciences
Kansas State University

January 10, 2012

1 Introduction

A programming language possesses syntax and semantics. Syntax refers to the spelling of the
language’s programs, and semantics refers to the meanings of the programs. A language’s syntax
is formalized by a grammar or syntax chart; such formalizations are found in the back of language
manuals. A language’s semantics should be formalized, too, and this is the topic of this chapter.
Before we begin, we might ask, “What do we gain by formalizing the semantics of a programming
language?” Consider the related question, “What was gained when language syntax was formalized
with BNF?”

• A language’s syntax definition standardizes the official syntax. This is crucial to users, who
require a guide to writing syntactically correct programs, and to implementors, who must
write a correct parser for the language’s compiler.

• The syntax definition permits a formal analysis of its properties, such as whether the definition
is LL(k), LR(k), or ambiguous.

• The syntax definition can be used as input to a compiler front-end generating tool, such as
YACC; it becomes, in effect, the implementation.

We derive similar benefits from a formal semantics definition:

• The semantics definition standardizes the official semantics of the language. This is cru-
cial to users, who require a guide to understanding the programs that they write, and to
implementors, who must write a correct code generator for the language’s compiler.

• The semantics definition permits a formal analysis of its properties, such as whether the defini-
tion is strongly typed, block structured, uses single-threaded data structures, is parallelizable,
etc.

• The semantics definition can be used as input to a compiler back-end generating tool [26, 31];
it becomes, in effect, the implementation.

Programming-language syntax was studied intensively in the 1960’s and 1970’s, and program-
ming language semantics is undergoing similar intensive study. Unlike the acceptance of BNF as
the standard for syntax definition, it is unlikely that a single definition method will take hold for
semantics—semantics is harder to formalize than syntax, and it has a wider variety of applications.
Semantics-definition methods fall roughly into three groups:

1
 • operational: the meaning of a well-formed program is the trace of computation steps that
results from processing the program’s input. Operational semantics is also called intensional
semantics, because the sequence of internal computation steps (the “intension”) is most im-
portant. For example, two differently coded programs that both compute factorial have
different operational semantics.

• denotational: the meaning of a well-formed program is a mathematical function from input

data to output data. The steps taken to calculate the output are unimportant; it is the relation
of input to output that matters. Denotational semantics is also called extensional semantics,
because only the “extension”—the visible relation between input and output—matters. Thus,
two differently coded versions of factorial have the same denotational semantics.

• axiomatic: a meaning of a well-formed program is a logical proposition (a “specification”)

that states some property about the input and output. For example, the proposition ∀x.x ≥
0 ⊃ ∃y.y = x! is an axiomatic semantics of a factorial program.

2 Underlying Principles of Semantics Methods

We survey the three semantic methods by applying each in turn to the world’s oldest and simplest
programming language, arithmetic. The syntax of our arithmetic language is

E ::= N | E1 + E2

where N stands for the set of numerals {0, 1, 2, ...}. Although this language has no notion of input
and output, it is computational.

2.1 Operational Semantics

There are several versions of operational semantics for arithmetic. The one that you learned as a
child is called a term rewriting system [6, 25]. It uses rule schemes generate computation steps.
There is just one rule scheme for arithmetic:

N1 + N2 ⇒ N′ where N′ is the sum of the numerals N1 and N2

The rule scheme states that adding two numerals is a computation step, e.g., 1 + 2 ⇒ 3 is one
computation step. An operational semantics of a program is a sequence of such computation steps.
For example, an operational semantics of (1 + 2) + (4 + 5) goes as follows:

(1 + 2) + (4 + 5) ⇒ 3 + (4 + 5) ⇒ 3 + 9 ⇒ 12

Three computation steps led to the answer, 12. An intermediate expression like 3 + (4 + 5) is a
“state,” so this operational semantics traces the states of the computation.
Another semantics for the example is (1 + 2) + (4 + 5) ⇒ (1 + 2) + 9 ⇒ 3 + 9 ⇒ 12. The
outcome is the same, and a set of rules that has this property is called confluent [25].
A structural operational semantics is a term-rewriting system plus a set of inference rules that
state precisely the context in which a computation step can be undertaken. (A structural opera-
tional semantics is sometimes called a “small-step semantics,” because each computation step is a
small step towards the final answer.) Say that we demand left-to-right computation of arithmetic
expressions. This is encoded as follows:

N1 + N2 ⇒ N′ where N′ is the sum of N1 and N2

2
 E1 ⇒ E′1 E2 ⇒ E′2
E1 + E2 ⇒ E′1 + E2 N + E2 ⇒ N + E′2
The first rule goes as before; the second rule states, if the left operand of an addition expression
can be rewritten, then do this. The third rule is the crucial one: if the right operand of an addition
expression can be rewritten and the left operand is already a numeral (completely evaluated), then
rewrite the right operand. Working together, the three rules force left-to-right evaluation.
Each computation step must be deduced by the rules. For (1 + 2) + (4 + 5), we deduce this
initial computation step:
1+2 ⇒ 3
(1 + 2) + (4 + 5) ⇒ 3 + (4 + 5)
Thus, the first step is (1+2)+(4+5) ⇒ 3+(4+5); note that we cannot deduce that (1+2)+(4+5) ⇒
(1 + 2) + 9. The next computation step is justified by this deduction:
4+5 ⇒ 9
3 + (4 + 5) ⇒ 3 + 9

The last deduction is simply 3 + 9 ⇒ 12, and we are finished. The example shows why the
semantics is “structural”: each computation step is explicitly embedded into the structure of the
overall program.
Operational semantics is often used to expose implementation concepts, like instruction coun-
ters, storage vectors, and stacks. For example, say our semantics of arithmetic must show how a
stack holds intermediate results. We use a state of form hs, ci, where s is the stack and c is the
arithmetic expression to evaluate. A stack containing n items is written v1 :: v2 :: ... :: vn :: nil,
where v1 is the topmost item and nil marks the bottom of the stack. The c component will be
written as a stack as well. The initial state for an arithmetic expression, p, is written hnil, p :: nili,
and computation proceeds until the state appears as hv :: nil, nili; we say that the result is v.
The semantics uses three rewriting rules:

hs, N :: ci ⇒ hN :: s, ci
hs, E1 + E2 :: ci ⇒ hs, E1 :: E2 :: add :: ci
hN2 :: N1 :: s, add :: ci ⇒ hN′ :: s, ci where N′ is the sum of N1 and N2

The first rule says that a numeral is evaluated by pushing it on the top of the stack. The second
rule decomposes an addition into its operands and operator, which must be computed individually.
The third rule removes the top two items from the stack and adds them. Here is the previous
example, repeated:

hnil, (1 + 2) + (4 + 5) :: nili
⇒ hnil, 1 + 2 :: 4 + 5 :: add :: nili
⇒ hnil, 1 :: 2 :: add :: 4 + 5 :: add :: nili
⇒ h1 :: nil, 2 :: add :: 4 + 5 :: add :: nili
⇒ h2 :: 1 :: nil, add :: 4 + 5 :: add :: nili
⇒ h3 :: nil, 4 + 5 :: add :: nili ⇒ ... ⇒ h12 :: nil, nili

This form of operational semantics is sometimes called a state-transition semantics, because

each rewriting rule operates upon the entire state. A state-transition semantics has no need for
structural operational-semantics rules.
The formulations presented here are typical of operational semantics. When one wishes to prove
properties of an operational-semantics definition, the standard proof technique is induction on the

3
 def eval(t, stack):
"""eval computes the meaning of t using stack.
parameters: t - an arithmetic term, parsed into a nested list of form:
term ::= N | ["+", term, term], where N is a string of digits
stack - a list of integers
returns: stack with the integer meaning of t pushed on its top.
"""
print "Evaluate", t, "with stack =", stack
if isinstance(t, str) and t.isdigit(): # is t a string of digits?
newstack = [int(t)] + stack # push the int onto the stack
else: # t is a list, ["+", t1, t2]
stack1 = eval(t[1], stack)
stack2 = eval(t[2], stack1)
answer = stack2[1] + stack2[0] # add top two stack values
newstack = [answer] + stack2[2:] # push answer onto popped stack
print "Evaluated", t, " Updated stack =", newstack
return newstack

Figure 1: Definitional interpreter in Python for stack-semantics of arithmetic

length of the computation. That is, to prove that a property, P , holds for an operational semantics,
one must show that P holds for all possible computation sequences that can be generated from the
rewriting rules. For an arbitrary computation sequence, it suffices to show that P holds no matter
how long the computation runs. Therefore, one shows (i) P holds after zero computation steps,
that is, at the outset, and (ii) if P holds after n computation steps, it holds after n + 1 steps. See
Nielson and Nielson [34] for examples.
Operational semantics lies close to implementation, and early forms of operational semantics
were definitional interpreters — implementations that generated the state-transition steps [13, 44].
Figure 1 displays a Python-coded definitional interpreter that generates the computation steps
of the stack-based arithmetic semantics, modelling the stack with a list argument and modelling
subexpression evaluation with recursive-function calls. (As an exercise, you should prove the inter-
preter prints a sequence of stacks that matches the one computed by the state-transition rules.) A
definitional interpreter is a powerful, practical tool for language definition and prototyping.

2.2 Denotational Semantics

Operational semantics emphasizes internal state transitions. For the arithmetic language, we were
distracted by questions about order of evaluation of subphrases, even though this issue is not at all
important to arithmetic. Further, the key property that the meaning of an expression is built from
the meanings of its subexpressions was obscured.
We use denotational semantics to establish that a program has an underlying mathematical
meaning that is independent of the computation strategy used to compute it. In the case of
arithmetic, an expression like (1 + 2) + (4 + 5) has the meaning, 12. The implementation that
computes the 12 is a separate issue, perhaps addressed by an operational semantics.
The assignment of meaning to programs is performed compositionally: the meaning of a phrase
is built from the meanings of its subphrases. We now see this in the denotational semantics of the
arithmetic language. First, we assert that meanings of arithmetic expressions must be taken from
the domain (“set”) of natural numbers, N at = {0, 1, 2, ...}, and there is a binary, mathematical
function, plus : N at × N at → N at, which maps a pair of natural numbers to their sum.

4
 The denotational semantics definition of arithmetic is simple and elegant:

E : Expression → N at
E[[N]] = N
E[[E1 + E2 ]] = plus(E[[E1 ]], E[[E2 ]])
The first line states that E is the name of the function that maps arithmetic expressions to
their meanings. Since there are two BNF constructions for expressions, E is completely defined by
the two equational clauses. (This is a Tarksi-style interpretation, as used in symbolic logic to give
meaning to logical propositions [49].) The interesting clause is the one for E1 + E2 ; it says that the
meanings of E1 and E2 are combined compositionally by plus. Here is the denotational semantics
of our example program:
E[[(1 + 2) + (4 + 5)]] = plus(E[[1 + 2]], E[[4 + 5]])
= plus(plus(E[[1]], E[[2]]), plus(E[[4]], E[[5]]))
= plus(plus(1, 2), plus(4, 5)) = plus(3, 9) = 12

Read the above as follows: the meaning of (1 + 2) + (4 + 5) equals the meanings of 1 + 2 and 4 + 5
added together. Since the meaning of 1 + 2 is 3, and the meaning of 4 + 5 is 9, the meaning of
the overall expression is 12. This reading says nothing about order of evaluation or run-time data
structures—it states only mathematical meaning.
Here is an alternative way of understanding the semantics; write a set of simultaneous equations
based on the denotational definition:

E[[(1 + 2) + (4 + 5)]] = plus(E[[1 + 2]], E[[4 + 5]])

E[[1 + 2]] = plus(E[[1]], E[[2]])
E[[4 + 5]] = plus(E[[4]], E[[5]])
E[[1]] = 1 E[[2]] = 2
E[[4]] = 4 E[[5]] = 5

Now, solve the equation set to discover that E[[(1 + 2) + (4 + 5)]] is 12.
Since denotational semantics states the meaning of a phrase in terms of the meanings of its
subphrases, its associated proof technique is structural induction. That is, to prove that a property,
P , holds for all programs in the language, one must show that the meaning of each construction in
the language has property P . Therefore, one must show that each equational clause in the semantic
definition produces a meaning with property P . In the case that a clause refers to subphrases (e.g.,
E[[E1 + E2 ]]), one may assume that the meanings of the subphrases have property P . Again, see
Nielson and Nielson [34] for examples.

2.3 Natural Semantics

A semantics method has been proposed that is halfway between operational semantics and deno-
tational semantics; it is called natural semantics. Like structural operational semantics, natural
semantics shows the context in which a computation step occurs, and like denotational semantics,
natural semantics emphasizes that the computation of a phrase is built from the computations of
its subphrases.
A natural semantics is a set of inference rules, and a complete computation in natural semantics
is a single, large derivation. The natural semantics rules for the arithmetic language are:

N ⇒ N

5
 E1 ⇒ n 1 E2 ⇒ n 2
where m is the sum of n1 and n2
E 1 + E2 ⇒ m
Read a configuration of the form E ⇒ n as “E evaluates to n.” The rules resemble a denotational
semantics written in inference rule form; this is no accident—natural semantics can be viewed as
a denotational-semantics variant where the internal calculations of meaning are made explicit and
the domains are left implicit. The internal calculations are seen in the natural semantics of our
example expression:
1 ⇒ 1 2 ⇒ 2 4 ⇒ 4 5 ⇒ 5
(1 + 2) ⇒ 3 (4 + 5) ⇒ 9
(1 + 2) + (4 + 5) ⇒ 12
Unlike denotational semantics, natural semantics does not claim that the meaning of a program
is necessarily “mathematical.” And unlike structural operational semantics, where a configuration
e ⇒ e′ says that e transits to an intermediate state, e′ , in natural semantics e ⇒ v asserts that
the final answer for e is v. For this reason, a natural semantics is sometimes called a “big-step
semantics.” An interesting drawback of natural semantics is that semantics derivations can be
drawn only for terminating programs.
The usual proof technique for proving properties of a natural semantics definition is induction
on the height of the derivation trees that are generated from the semantics. Once again, see Nielson
and Nielson [34].

2.4 Axiomatic Semantics

An axiomatic semantics produces properties of programs rather than meanings. The derivation of
these properties is done by an inference rule set that looks somewhat like a natural semantics.
As an example, say that we wish to prove even-odd properties of programs in arithmetic and
our set of properties is simply {is even, is odd}. For example, 2 : is even and (2 + 3) : is odd both
hold true. We can define an axiomatic semantics to do this:

N : is even if N mod 2 = 0 N : is odd if N mod 2 = 1

(
E1 : p 1 E2 : p 2 is even if p1 = p2
where p3 =
E1 + E2 : p 3 is odd otherwise
The derivation of the even-odd property of our example program is:
1 : is odd 2 : is even 4 : is even 5 : is odd
1 + 2 : is odd 4 + 5 : is odd
(1 + 2) + (4 + 5) : is even
In the usual case, the properties to be proved of programs are expressed in the language of pred-
icate logic; see Section 3.7. Also, axiomatic semantics has strong ties to the abstract interpretation
of denotational and natural semantics definitions; see Section 4.

3 Semantical Principles of Programming Languages

The semantics methods shine when they are applied to programming languages—primary features
of a language are made prominent, and subtle features receive proper mention. Ambiguities and
anomalies stand out like the proverbial sore thumb. In this section, we use a classic block-structured
imperative language to demonstrate. Denotational semantics will be emphasized, but excerpts from
the other semantics formalisms will be provided for comparison.

6
 P ∈ Program I ∈ Identifier = alphabetic strings
D ∈ Declaration V ∈ Variable = { X, Y, Z } ⊆ Identifier
C ∈ Command N ∈ Numeral = { 0, 1, 2, ... }
E ∈ Expression

P ::= C.
D ::= proc I = C
C ::= V:=E | C1 ; C2 | begin D in C end | call I | while E do C od
E ::= N | E1 + E2 | E1 not= E2 | V

Figure 2: Language Syntax Rules

3.1 Language Syntax and Informal Semantics

The syntax of the programming language is presented in Figure 2. As stated in the figure, there
are four “levels” of syntax constructions in the language, and the topmost level, Program, is the
primary one. The language is a while-loop language with local, nonrecursive procedure definitions.
For simplicity, variables are predeclared and there are just three of them—X, Y, and Z. A program,
C., operates as follows: an input number is read and assigned to X’s location. Then the body, C, of
the program is evaluated, and upon completion, the storage vector holds the results. For example,
this program computes n2 for a positive input n; the result is found in Z’s location:
begin proc INCR = Z:= Z+X; Y:= Y+1
in Y:= 0; Z:= 0; while Y not= X do call INCR od end.

It is possible to write nonsense programs in the language; an example is: A:=0; call B. Such
programs have no meaning, and we will not attempt to give semantics to them.

3.2 Domains for Denotational Semantics

To give a denotational semantics to the sample language, we must state the sets of meanings, called
domains, that we use. Our imperative, block-structured language has two primary domains: (i) the
domain of storage vectors, called Store, and (ii) the domain of symbol tables, called Environment.
There are also secondary domains of booleans and natural numbers. The primary domains and
their operations are displayed in Figure 3.
The domains and operations deserve study. First, the Store domain states that a storage
vector is a triple. (Recall that programs have exactly three variables.) The operation lookup
extracts a value from the store, e.g., lookup(2, h1, 3, 5i) = 3, and update updates the store, e.g.,
update(2, 6, h1, 3, 5i) = h1, 6, 5i. Operation init store creates a starting store. We examine check
momentarily.
The environment domain states that a symbol table is a list of identifier-value pairs. For
example, if variable X is the name of location 1, and P is the name of a procedure that is a “no-
op,” then the environment that holds this information would appear (X, 1) :: (P, id) :: nil, where
id(s) = s. (Procedures will be discussed momentarily.) Operation find locates the binding for an
identifier in the environment, e.g., find(X, (X, 1) :: (P, id) :: nil) = 1, and bind adds a new binding,
e.g., bind(Y, 2, (X, 1) :: (P, id) :: nil) = (Y, 2) :: (X, 1) :: (P, id) :: nil. Operation init env creates an
environment to start the program.
In the next section, we will see that the job of a command, e.g., an assignment, is to update
the store—the meaning of a command is a function that maps the current store to the updated

7
 Store = {hn1 , n2 , n3 i | ni ∈ N at, i ∈ 1..3}

lookup : {1, 2, 3} × Store → N at

lookup(i, hn1 , n2 , n3 i) = ni
update : {1, 2, 3} × N at × Store → Store
update(1, n, hn1 , n2 , n3 i) = hn, n2 , n3 i
update(2, n, hn1 , n2 , n3 i) = hn1 , n, n3 i
update(3, n, hn1 , n2 , n3 i) = hn1 , n2 , ni
init store : N at → Store
init store(n) = hn, 0, 0i
check : (Store → Store⊥ ) × Store⊥ → Store⊥ where Store⊥ = Store ∪ {⊥}
check(c, a) = if (a = ⊥) then ⊥ else c(a)

Environment = (Identifier × Denotable)∗

where A∗ is a list of A-elements, a1 :: a2 :: ... :: an :: nil, n ≥ 0
and Denotable = {1, 2, 3} ∪ (Store → Store⊥ )

find : Identifier × Environment → Denotable

find(i, nil) = 0
find(i, (i′ , d) :: rest) = if (i = i′ ) then d else find(i, rest)
bind : Identifier × Denotable × Environment → Environment
bind(i, d, e) = (i, d) :: e
init env : Environment
init env = (X, 1) :: (Y, 2) :: (Z, 3) :: nil

Figure 3: Semantic Domains

one. (That’s why a “no-op” command is the identity function, id(s) = s, where s ∈ Store.)
But sometimes commands “loop,” and no updated store appears. We use the symbol, ⊥, read
“bottom,” to stand for a looping store, and we use Store⊥ = Store ∪ {⊥} as the possible outputs
from commands. Therefore, the meaning of a command is a function of form Store → Store⊥ .
It is impossible to recover from looping, so if there is a command sequence, C1 ; C2 , and C1 is
looping, then C2 cannot proceed. The check operation is used to watch for this situation.
Finally, here are two commonly used notations. First, functions like id(s) = s are often refor-
matted to read id = λs.s; in general, for f (a) = e, we write f = λa.e, that is, we write the argument
to the function to the right of the equals sign. This is called lambda notation, and stems from the
lambda calculus, an elegant formal system for functions [4]. The notation f = λa.e emphasizes that
(i) the function λa.e is a value in its own right, and (ii) the function’s name is f .
Second, it is common to revise a function that takes multiple arguments, e.g., f (a, b) = e, so
that it takes the arguments one at a time: f = λa.λb.e. So, if the arity of f was A × B → C, its
new arity is A → (B → C). This reformatting trick is named currying, after Haskell Curry, one
of the developers of the lambda calculus.

3.3 Denotational Semantics of Programs

Figure 4 gives the denotational semantics of the programming language. Since the syntax of the
language has four levels, the semantics is organized into four levels of meaning. For each level,

8
 P : P rogram → N at → N at⊥
P[[C.]] = λn.C[[C]]init env (init store n)
D : Declaration → Environment → Environment
D[[proc I = C]] = λe.bind(I, C[[C]]e, e)
C : Command → Environment → Store → Store⊥
C[[V:=E]] = λe.λs.update(find(V, e), E[[E]]e s, s)
C[[C1 ; C2 ]] = λe.λs.check(C[[C2 ]]e, C[[C1 ]]e s)
C[[begin D in C end]] = λe.λs.C[[C]](D[[D]]e)s
C[[call I]] = λe.find(I, e)
C[[while E do C od]] = λe. i≥0 wi
S

w0 = λs.⊥
where
wi+1 = λs.if E[[E]]e s then check(wi , C[[C]]e s) else s
E : Expression → Environment → Store → (N at ∪ Bool)
E[[N]] = λe.λs.N
E[[E1 + E2 ]] = λe.λs.plus(E[[E1 ]]e s, E[[E2 ]]e s)
E[[E1 not= E2 ]] = λe.λs.notequals(E[[E1 ]]e s, E[[E2 ]]e s)
E[[V]] = λe.λs.lookup(find(V, e), s)

Figure 4: Denotational Semantics

we define a valuation function, which produces the meanings of constructions at that level. For
example, at the Expression level, the constructions are mapped to their meanings by E.
What is the meaning of the expression, say, X+5? This would be E[[X+5]], and the meaning
depends on which location is named by X and what number is stored in that location. Therefore,
the meaning is dependent on the current value of the environment and the current value of the
store. So, if the current environment is e0 = (P, λs.s) :: (X, 1) :: (Y, 2) :: (Z, 3) :: nil and the current
store is s0 = h2, 0, 0i, then the meaning of X+5 is 7:

E[[X+5]]e0 s0 = plus(E[[X]]e0 s0 , E[[5]]e0 s0 )

= plus(lookup(find(X, e0 ), s0 ), 5)
= plus(lookup(1, s0 ), 5) = plus(2, 5) = 7
As this simple derivation shows, data structures like the symbol table and storage vector are
modelled by the environment and store arguments. This pattern is used throughout the semantics
definition.
As noted in the previous section, a command updates the store. Precisely stated, the valuation
function for commands is: C : Command → Environment → Store → Store⊥ . For example,
for e0 and s0 given above, we see that

C[[Z:=X+5]]e0 s0 = update(find(Z, e0 ), E[[X+5]]e0 s0 , s0 ) = update(3, 7, s0 ) = h2, 0, 7i

But a crucial point about the meaning of the assignment is that it is a function upon stores. That
is, if we are uncertain of the current value of store, but we know that the environment for the
assignment is e0 , then we can conclude

C[[Z:=X+5]]e0 = λs.update(3, plus(lookup(1, s), 5), s)

That is, the assignment with environment e0 is a function that updates a store at location 3.

9
 Next, consider this example of a command sequence:

C[[Z:=X+5; call P]]e0 s0 = check(C[[call P]]e0 , C[[Z:=X+5]]e0 s0 )

= check(find(P, e0 ), h2, 0, 7i) = check(λs.s, h2, 0, 7i)
= (λs.s)h2, 0, 7i = h2, 0, 7i

As noted in the earlier section, the check operation verifies that the first command in the se-
quence produces a proper output store; if so, the store is handed to the second command in the
sequence. Also, we see that the meaning of call P is the store updating function bound to P in
the environment.
Procedures are placed in the environment by declarations, as we see in this example: let e1
denote (X, 1) :: (Y, 2) :: (Z, 3) :: nil:

C[[begin proc P = Y:=Y in Z:=X+5; call P end]]e1 s0

= C[[Z:=X+5; call P]](D[[proc P = Y:=Y ]]e1 )s0
= C[[Z:=X+5; call P]](bind(P, C[[Y:=Y]]e1 , e1 ))s0
= C[[Z:=X+5; call P]](bind(P, λs.update(2, lookup(2, s), s), e1 ))s0
= C[[Z:=X+5; call P]]((P, id) :: e1 )s0
where id = λs.update(2, lookup(2, s), s) = λs.s (∗)
= C[[Z:=X+5; call P]]e0 s0 = h2, 0, 7i

The equality marked by (∗) is significant; we can assert that the function
λs.update(2, lookup(2, s), s) is identical to λs.s by appealing to the extensionality law of
mathematics: if two functions map identical arguments to identical answers, then the functions are
themselves identical. The extensionality law can be used here because in denotational semantics
the meanings of program phrases are mathematical—functions. In contrast, the extensionality law
cannot be used in operational semantics calculations.
Finally, we can combine our series of little examples into the semantics of a complete program:

P[[begin proc P = Y:=Y in Z:=X+5; call P end.]]2

= C[[begin proc P = Y:=Y in Z:=X+5; call P end ]]init env (init store 2)
= C[[begin proc P = Y:=Y in Z:=X+5; call P end]]e1 s0
= h2, 0, 7i

3.4 Semantics of the While Loop

The most difficult clause in the semantics definition is the one for the while-loop. Here is some
intuition: to produce an output store, the loop while E do C od must terminate after some finite
number of iterations. To measure this behavior, let whilei E do C od be a loop that can iterate
at most i times—if the loop runs more than i iterations, it becomes exhausted, and its output is
⊥. For example, for input store h4, 0, 0i, the loop whilek Y not= X do Y:=Y+1 od can produce the
output store h4, 4, 0i only when k is greater than 4. (Otherwise, the output is ⊥.)
It is easy to conclude that the family, whilei E do C od, for i ≥ 0, can be written equivalently
as:
while0 E do C od = “exhausted” (that is, its meaning is λs.⊥)
whilei+1 E do C od = if E then C ; whilei E do C od else skip fi
When we refer back to Figure 3, we draw these conclusions:

C[[while0 E do C od]]e = w0
C[[whilei+1 E do C od]]e = wi+1

10
 e ⊢ D ⇒ e′ e′ , s ⊢ C ⇒ s′
e ⊢ proc I = C ⇒ bind(I, (e, C), e)
e, s ⊢ begin D in C end ⇒ s′

l = find(V, e) e, s ⊢ E ⇒ n e, s ⊢ C1 ⇒ s′ e, s′ ⊢ C2 ⇒ s′′
e, s ⊢ V:=E ⇒ update(l, n, s) e, s ⊢ C1 ; C2 ⇒ s′′
(e′ , C ′ ) = find(I, e) e′ , s ⊢ C ′ ⇒ s′ e, s ⊢ E ⇒ f alse
e, s ⊢ call I ⇒ s′ e, s ⊢ while E do C od ⇒ s
e, s ⊢ E ⇒ true e, s ⊢ C ⇒ s′ e, s′ ⊢ while E do C od ⇒ s′′
e, s ⊢ while E do C od ⇒ s′′

Figure 5: Natural Semantics

Since the behavior of a while loop must be the “union” of the behaviors of the whilei -loops, we
conclude that C[[while E do C od]]e = i≥0 wi . The semantic union operation is well defined because
S

each wi is a function from the set Store → Store⊥ , and a function can be represented as a set of
argument-answer pairs. (This is called the graph of the function.) So, i≥0 wi is the union of the
S

graphs of the wi functions1 .

The definition of C[[whileEdoCod]] is succinct, but it is awkward to use in practice. An intuitive
way of defining the semantics is:

C[[while E do C od]]e = w
where w = λs.if E[[E]]e s then check(w, C[[C]]e s) else s

The problem here is that the definition of w is circular, and circular definitions can be malformed.
Fortunately, this definition of w can be claimed to denote the function i≥0 wi because the following
S

equality holds: [ [
wi = λs.if E[[E]]e s then check( wi , C[[C]]e s) else s
i≥0 i≥0

So, i≥0 wi is a solution—a fixed point—of the circular definition, and in fact it is the smallest
S

function that makes the equality hold. Therefore, it is the least fixed point.
Typically, the denotational semantics of the while-loop is presented by the circular definition,
and the claim is then made that the circular definition stands for the least fixed point. This is called
fixed-point semantics. We have omitted many technical details regarding fixed-point semantics;
these are available in several texts [15, 45, 47, 51].

3.5 The Natural Semantics of the Language

We can compare the denotational semantics of the imperative language with a natural semantics
formulation. The semantics of several constructions appear in Figure 5.
A command configuration has the form e, s ⊢ C ⇒ s′ , where e and s are the “inputs” to
command C and s′ is the “output.” To understand the inference rules, read them “bottom up.”
For example, the rule for I:=E says, given the inputs e and s, one must first find the location, l,
1
Several important technical details have been glossed over. First, pairs of the form (s, ⊥) are ignored when the
union of the graphs is performed. Second, for all i ≥ 0, the graph of wi is a subset of the graph of wi+1 ; this ensures
the union of the graphs is a function.

11
 let e0 = (X, 1) :: (Y, 2) :: (Z, 3) :: nil
s0 = h2, 0, 0i, s1 = h2, 1, 0i
E0 = Y not=1, C0 = Y:=Y+1
C00 = while E0 do C0 od

2 = find(Y, e0 ) e0 , s0 ⊢ Y+1 ⇒ 1 e0 , s1 ⊢ E0 ⇒ false

e0 , s0 ⊢ E0 ⇒ true
e0 , s0 ⊢ C0 ⇒ s1 e0 , s1 ⊢ C00 ⇒ s1
e0 , s0 ⊢ C00 ⇒ s1

Figure 6: Natural Semantics Derivation

bound to I and then calculate the output, n, for E. Finally, l and n are used to update s, producing
the output.
The rules are denotational-like, but differences arise in several key constructions. First, the
semantics of a procedure declaration binds I not to a function but to an environment-command
pair called a closure. When procedure I is called, the closure is disassembled, and its text and
environment are executed. Since a natural semantics does not use function arguments, it is called
a first-order semantics. (Denotational semantics is sometimes called a higher-order semantics.)
Second, the while-loop rules are circular. The second rule states, in order to derive a while-loop
computation that terminates in s′′ , one must derive (i) the test, E is true, (ii) the body, C, outputs
s′ , and (iii) using e and s′ , one can derive a terminating while-loop computation that outputs s′′ .
The rule makes one feel that the while-loop is “running backwards” from its termination to its
starting point, but a complete derivation, like the one shown in Figure 6, shows that the iterations
of the loop can be read from the root to the leaves of the derivation tree.
One important aspect of the natural semantics definition is that derivations can be drawn only
for terminating computations. A nonterminating computation is equated with no computation at
all.

3.6 The Operational Semantics of the Language

A fragment of the structural operational semantics of the imperative language is presented in Figure
7. For expressions, a computation step takes the form e ⊢ hE, si ⇒ E′ , where e is the environment,
E is the expression that is evaluated, s is the current store, and E′ is E rewritten. In the case of a
command, C, a step appears e ⊢ hC, si ⇒ hC′ , s′ i, because computation on C might also update
the store. If the computation step on C “uses up” the command, the step appears e ⊢ hC, si ⇒ s′ .
The rules in the figure are more tedious than those for a natural semantics, because the indi-
vidual computation steps must be defined, and the order in which the steps are undertaken must
also be defined. This complicates the rules for command composition, for example. On the other
hand, the rewriting rule for the while-loop merely decodes the loop as a conditional command.
The rules for procedure call are awkward; as with the natural semantics, a procedure, I, is
represented as a closure of the form (e′ , C′ ). Since C′ must execute with environment, e′ , which is
different from the environment that exists where procedure I is called, the rewriting step for call I
must retain two environments; a new construct, use e′ in C′ , remembers that C′ must use e′ (and
not e). A similar trick is used in begin D in C end.
Unlike a natural semantics definition, a computation can be written for a nonterminating pro-
gram; the computation is a state sequence of countably infinite length.

12
 e ⊢ hn1 + n2 , si ⇒ n3 where n3 is the sum of n1 and n2

e ⊢ hE, si ⇒ E′
e ⊢ hI:=E, si ⇒ hI:=E′ , si
e ⊢ hI:=n, si ⇒ update(l, n, s) where find(I, e) = l
e ⊢ hC1 , si ⇒ hC′1 , s′ i e ⊢ hC1 , si ⇒ s′
e ⊢ hC1 ; C2 , si ⇒ hC′1 ; C2 , s′ i e ⊢ hC1 ; C2 , si ⇒ hC2 , s′ i
e ⊢ hwhile E do C od, si ⇒ hif E then C ; while E do C od else skip fi, si
e ⊢ hcall I, si ⇒ huse e′ in C′ , si where find(I, e) = (e′ , C′ )
e′ ⊢ hC, si ⇒ hC′ , s′ i e′ ⊢ hC, si ⇒ s′
e ⊢ huse e′ in C, si ⇒ huse e′ in C′ , s′ i e ⊢ huse e′ in C, si ⇒ s′
e ⊢ proc I = C ⇒ bind(I, (e, C), e)
e ⊢ D ⇒ e′
e ⊢ hbegin D in C end, si ⇒ huse e′ in C, si

Figure 7: Structural Operational Semantics

{[E/I]P } I:=E {P }

P ⊃ P′ {P ′ } C {Q′ } Q′ ⊃ Q {P } C1 {Q} {Q} C2 {R}

{P } C {Q} {P } C1 ; C2 {R}
{P ∧ E} C1 {Q} {P ∧ ¬E} C2 {Q} {P ∧ E} C {P }
{P } if E then C1 else C2 fi {Q} {P } while E do C od {P ∧ ¬E}

Figure 8: Axiomatic Semantics Inference Rules

3.7 An Axiomatic Semantics of the Language

An axiomatic semantics computes upon properties of stores, because programs are understood as
“knowledge transformers.” For example, the property X = 3 ∧ Y > X asserts knowledge about
the values of X and Y (namely, the store holds 3 at X’s location and a number in Y’s location
that is even larger). The meaning of a command, C, is stated in terms of configurations of form,
{P } C {Q}, stating that, if predicate (knowledge) P holds true then C generates knowledge Q
upon termination (if C does indeed terminate). For example, all of these configurations are true
assertions of the command, X:=X+1: (i) {X > 2} X:=X+1 {X > 3}; (ii) {Y > X} X:=X+1 {Y > X − 1};
(iii) {X = 3 ∧ Y > X} X:=X+1 {X = 4 ∧ Y > X − 1}.
Figure 7 displays the rules for the primary command constructions. The rule for I:=E states
that an assignment transforms knowledge about E into knowledge about E’s “new name,” I. (To
understand this, recall that [E/I]P stands for the substitution of E for all free occurrences of I in
P . For example, [Y+1/X](X>3) is Y+1>3.) We can use the rule to prove that X:=X+1 transforms
X+1>3 into X>3, that is, {X+1>3} X:=X+1 {X>3}. Again, I:=E transforms knowledge about E into

13
 assert {TOTAL = X+Y}
let P0 be TOTAL = X+Y while X not= 0 do
P1 be TOTAL = X+(Y+1), P2 be TOTAL = (X-1)+(Y+1) invariant {TOTAL = X+Y}
X:= X - 1
E0 = X not= 0, C0 = X:=X-1;Y:=Y+1
assert {TOTAL = X+(Y+1)}
Y:= Y + 1
{P2 } X:=X-1 {P1 } {P1 } Y:=Y+1 {P0 }
(P0 ∧ E0 ) ⊃ P2 P0 ⊃ P0 assert {TOTAL = X+Y}
{P2 } C0 {P0 } od
{P0 ∧ E0 } C0 {P0 } assert {TOTAL = X+Y
{P0 } while E0 do C0 od {P0 ∧ ¬E0 } and not(X not= 0)}
implies {TOTAL = Y}

Figure 9: Axiomatic Semantics Derivation

knowledge about E’s “new name,” I.

The second rule in the Figure uses logical implication to deduce new knowledge; we deduce
that {X>2} X:=X+1 {X>3}, because X+1>3 implies X>2. The properties of command composition
are defined by the third rule: knowlege generated by command C1 passes to command C2 .
The fourth rule, for the if-command, shows how to make a property hold upon termination
regardless of which arm of the conditional is evaluated. For example, the rule proves {X 6= 0} if X <
0 then Y:= − X else Y:=X fi {Y > 0}, because knowledge from the test, X < 0, lets us prove both
{X < 0 ∧ X 6= 0} Y:= − X {Y > 0} and also {¬(X < 0) ∧ X 6= 0} Y:=X {Y > 0}.
The most fascinating rule is the last one, for while E do C od. The loop’s body, C, is “repeatable
code,” which means whatever knowledge, I, is required to use C must be regenerated to reuse C —
{E ∧ I} C {I}! I is called an invariant, because it remains true for all the repetitions of the loop.
We conclude that I holds true if and when the loop terminates.
Another viewpoint is that a loop is kind of “game” played in rounds. If C lists the moves taken
in one round, then the invariant, I, is the strategy one uses to “keep the lead” and eventually win.
The game ends when the loop’s test, E, goes false.
Here is an example: We play a pebble game, where pebbles can be moved only one at a time.
There are two boxes of pebbles, named X and Y. To win the game, all the pebbles must be moved into
Y’s box without losing any. Here is how we might play one round of the game: X:= X-1; Y:= Y+1.
Our strategy is encoded by the invariant, TOTAL = X+Y, which says that we do not lose any pebbles
when we move them:

{TOTAL = X+Y} X:= X-1; Y:= Y+1 {TOTAL = X+Y}

The completed game is this loop program, while X not= 0 do X:= X-1; Y:= Y+1 od, and the
proof that the loop generates a victory is listed in Figure 9, which shows at the end that TOTAL = Y,
that is, all the pebbles rest in Y’s box. The derivation is difficult to read, but when reformat-
ted vertically, as seen in the right half of the Figure, it shows clearly how the input knowledge,
TOTAL = X+Y, is transformed into the output knowledge, TOTAL = Y.
The key to building the proof is determining a loop invariant. Since the goal was to prove
TOTAL = Y, this made TOTAL = X+Y useful, because X:= X-1 eventually lowers X to zero.2 With
the invariant in hand, it is easy to work backwards, from the end of the loop body, to the top,
to calculate that the loop body is indeed “repeatable code”: The rule for assignment proves both
2
The loop terminates only if X’s value begins as a nonnegative. The laws in Figure 8 do not guarantee termination.
This requires additional logical machinery.

14
{TOTAL = X+(Y+1)} Y:=Y+1 {TOTAL = X+Y}, and also {TOTAL = (X−1)+(Y+1)} X:=X-1 {TOTAL =
X + (Y + 1)}. Finally, TOTAL = (X − 1) + (Y + 1) implies TOTAL = X+Y.
There are three ways of stating the semantics of a command in an axiomatic semantics:

• relational semantics: The meaning of C is the set of P, Q pairs for which {P } C {Q} holds.
Termination is not demanded of C. (This is called “partial correctness.”)

• postcondition semantics: The meaning of C is a function from an input predicate to an output

predicate. We write slp(P, C) = Q; this means that {P } C {Q} holds, and for all Q′ such
that {P } C {Q′ } holds, it is the case that Q implies Q′ . This is also called strongest liberal
postcondition semantics. When termination (“total correctness”) is demanded also of C, the
name becomes strongest postcondition semantics.

• precondition semantics: The meaning of C is a function from an output predicate to an input

predicate. We write wlp(C, Q) = P ; this means that {P } C {Q} holds, and for all P ′ such
that {P ′ } C {Q} holds, it is the case that P ′ implies P . This is also called weakest liberal
precondition semantics. When termination is demanded also of C, the name becomes weakest
precondition semantics.

4 Practical Impact

Research on programming-language semantics showed how a language can be defined precisely, its
correctness properties proved, and its implementation realized. Indeed, the area of formal methods
(cf. Chapter 116) is an adaptation of the semantics methods from computer languages to computer
programs — how a program can be specified precisely, its correctness properties proved, and its
specification implemented.
Operational semantics, having the longest life of the semantic approaches, is most entrenched
within software development. From operational semantics came virtual machines to which lan-
guages can be translated. Definitional interpreters are now the norm for prototyping new languages,
especially ”little” or “domain-specific” languages, which are designed for problem solving in a lim-
ited application domain, e.g., file-linking (Make), web-page layout (HTML), spreadsheet layout
(Excel), or linear algebra (Matlab). Scripting languages (see Chapter 110) are also implemented in
definitional-interpreter style.
Axiomatic semantics has undergone a significant revival, not only as the starting point for
specification writing and verification in formal-methods work, but as the language for description
and analysis of secure and safety-critical software systems, where correctness properties, above
all, must be stated so that there can validation or justification, whether by testing, monitoring,
or theorem proving. Indeed, the Object Control Language (OCL) used in the Unified Modelling
Language for software blueprinting is a derivative of the classic axiomatic semantics notation. (See
Volume 2 of this Handbook.) A wide variety of proof assistants and logical frameworks are available
for helping a designer state and validate crucial properties of software, e.g., ACL2 [24], PVS [38],
Isabelle/HOL [35], and Coq [41].
The primary impact of denotational semantics has been to the design of modern programm-
ming languages. The modelling of programming constructions as functions that operate on storage
motivated many designers to add such functions as primitive constructions to the programming
language itself — the results are (i) higher-order constructions, such as the anonymous functions in
ML and Java; (ii) generic and polymorphic constructions, such as class templates in C++ and Scala;
and (iii) reflective constructions, like that found in JavaBeans and 3-Lisp. The importance of poly-

15
morphic constructions to modern-day software assembly has stimulated extensions of denotational
semantics into “higher-order” formats that are expressed within type theory [39, 36].
Within the subarea of programming-languages research, the semantics methods play a central
role. Language designers use semantics definitions to formalize their creations, as was done during
the development of Ada [10] and after development for Scheme [43] and Standard ML [27]. Software
tools are readily available to prototype a syntax-plus-semantics definition into an implementation
[31, 26, 5, 8].
A major success of formal semantics is the analysis and synthesis of data-flow analysis and type-
inference algorithms from semantics definitions. This subject area, called abstract interpretation
[3, 7, 33], uses algebra techniques to map semantic definitions from their “concrete” (execution)
definition to their “abstract” (homomorphic property) definition. The technique can be used to
extract properties from the definitions, generate data flow and type inference, and prove program
correctness or code-improvement transformations. Most automated methods for program validation
use abstract interpretation.

5 Research Issues

The techniques in this chapter have proved successful for defining, improving, and implementing se-
quential programming languages. But new language and software paradigms present new challenges
to the semantics methods.
Challenging issues arise in the object-oriented programming paradigm. Not only can objects
be arguments (“messages”) to other objects’ procedures (“methods”), but coercion laws based on
inheritance allow controlled mismatches between arguments and parameters. For example, an ob-
ject argument that contains methods for addition, subtraction, and multiplication is bound to a
method’s parameter that expects an object with just addition and subtraction methods. Care-
lessly defined coercions lead to unsound programs, so semantics definitions must be extended with
inheritance hierarchies [16, 40]. See Chapter 107 for details.
Yet another challenging topic is defining communication as it arises in distributed programming,
where multiple processes (threads of execution) synchronize through communication. Structural
operational semantics has been adapted to formalize such systems. More importantly, the protocol
used by a system lies at the center of the system’s semantics; semantics approaches based on process
algebra [12, 20, 28] have been developed that express a protocol as a family of simultaneous algebra
equations that must be “solved” to yield a convergent solution. See Chapter 112.
A current challenge is applying semantics methods to define and explain programs that exploit
the architecture of multi-core processors, where subcomputations and their storage requirements
must be allocated to processor cores and their associated cache hierarchy [18]. See Chapter 34 for
background.
Finally, a longstanding crucial topic is the relationship between different forms of semantic
definitions: If one has, say, both a denotational semantics and an axiomatic semantics for the
same programming language, in what sense do the semantics agree? Agreement is crucial, since
a programmer might use the axiomatic semantics to reason about the properties of programs,
whereas a compiler writer might use the denotational semantics to implement the language. This
question generalizes to the problem of refinement of software specifications — see Chapter 116. In
mathematical logic, one uses the concepts of soundness and completeness to relate a logic’s proof
system to its interpretation, and in semantics there are similar notions of soundness and adequacy to
relate one semantics to another [15, 37]. Important as these properties are, they are quite difficult
to realize in practice [1].

16
6 Defining Terms

Axiomatic semantics: The meaning of a program as a property or specification in logic.

Denotational semantics: The meaning of a program as a compositional definition of a mathe-

matical function from the program’s input data to its output data.

Fixed-point semantics: A denotational semantics where the meaning of a repetitive structure,

like a loop or recursive procedure, is expressed as the smallest mathematical function that
satisfies a recursively defined equation.

Loop invariant: In axiomatic semantics, a logical property of a while-loop that holds true no
matter how many iterations the loop executes.

Natural semantics: A hybrid of operational and denotational semantics that shows computation
steps performed in a compositional manner. Also known as a “big-step semantics.”

Operational semantics: The meaning of a program as calculation of a trace of its computation

steps on input data.

Strongest postcondition semantics: A variant of axiomatic semantics where a program and

an input property are mapped to the strongest proposition that holds true of the program’s
output.

Structural operational semantics: A variant of operational semantics where computation steps

are performed only within prespecified contexts. Also known as a “small-step semantics.”

Weakest precondition semantics: A variant of axiomatic semantics where a program and an

output property are mapped to the weakest proposition that is necessary of the program’s
input to make the output property hold true.

References

[1] S. Abramsky, R. Jagadeesan, and P. Malacaria. Full abstraction for PCF. In Proc. Theoretical
Aspects of Computer Software, TACS94, Lecture Notes in Computer Science 789, pages 1–15.
Springer, 1994.

[2] K. Apt. Ten years of Hoare’s logic: A survey–part I. ACM Trans. Programming Languages
and Systems, 3:431–484, 1981.

[3] B. Blanchet, et al. A static analyzer for large safety-critical software. In Proc. Programming
Language Design and Implementation, pages 196–207. ACM Press, 2003.

[4] H. Barendregt. The Lambda Calculus: Its Syntax and Semantics. North Holland, Amsterdam,
1984.

[5] D. F. Brown, H. Moura, and D. A. Watt. Actress: an action semantics directed compiler gen-
erator. In CC’92, Proceedings of the 4th International Conference on Compiler Construction,
Paderborn, Lecture Notes in Computer Science 641, pages 95–109. Springer-Verlag, 1992.

[6] M. Clavel, et al. All About Maude - A High-Performance Logical Framework. Springer-Verlag,
2007.

17
 [7] P. Cousot and R. Cousot. Abstract interpretation: a unified lattice model for static analysis of
programs. In Proc. 4th ACM Symp. on Principles of Programming Languages, pages 238–252.
ACM Press, 1977.

[8] Th. Despeyroux. Executable specification of static semantics. In G. Kahn, D.B. MacQueen,
and G. Plotkin, editors, Semantics of Data Types, pages 215–234. Lecture Notes in Computer
Science 173, Springer-Verlag, 1984.

[9] E.W. Dijkstra. A Discipline of Programming. Prentice-Hall, 1976.

[10] V. Donzeau-Gouge. On the formal description of Ada. In N.D. Jones, editor, Semantics-
Directed Compiler Generation. Lecture Notes in Computer Science 94, Springer-Verlag, 1980.

[11] G. Dromey. Program Derivation. Addison-Wesley, Sydney, 1989.

[12] J. Fokkink. Introduction to Process Algebra. Springer-Verlag, 2010.

[13] D. Friedman, M. Wand, and C. Haynes. Essentials of Programming Languages, 2d ed. MIT
Press, 2001.

[14] D. Gries. The Science of Programming. Springer, 1981.

[15] C. Gunter. Semantics of Programming Languages. MIT Press, Cambridge, MA, 1992.

[16] C. Gunter and J. Mitchell, editors. Theoretical Aspects of Object-Oriented Programming. MIT
Press, Cambridge, MA, 1994.

[17] M. Hennessy. The Semantics of Programming Languages: An Elementary Introduction Using

Structured Operational Semantics. Wiley, New York, 1991.

[18] M. Herlihy and N. Shavit. Art of Multiprocessor Programming. Morgan Kaufmann, 2008.

[19] C.A.R. Hoare. An axiomatic basis for computer programming. Commun. ACM, 12:576–580,
1969.

[20] C.A.R. Hoare. Communicating Sequential Processes. Prentice-Hall, 1985.

[21] C.A.R. Hoare and N. Wirth. An axiomatic definition of the programming language Pascal.
Acta Informatica, 2:335–355, 1973.

[22] C.B. Jones. Software Development: A Rigorous Approach. Prentice-Hall, 1980.

[23] G. Kahn. Natural semantics. In Proc. STACS ’87, pages 22–39. Lecture Notes in Computer
Science 247, Springer, Berlin, 1987.

[24] M. Kaufmann, P. Manolios, and J.S. Moore. Computer-Aided Reasoning: ACL2 Case Studies.
Kluwer, 2000.

[25] J.W. Klop. Term rewriting systems. In T. Maibaum S. Abramsky, D. Gabbay, editor, Handbook
of Logic in Computer Science, volume 2, pages 2–117. Oxford University Press, 1992.

[26] P. Lee. Realistic Compiler Generation. The MIT Press, Cambridge, Massachusetts, 1989.

[27] R. Milner, M. Tofte, and R. Harper. The Definition of Standard ML. The MIT Press, 1990.

18
[28] Robin Milner. Communication and Concurrency. Prentice-Hall, 1989.

[29] J.C. Mitchell. Foundations for Programming Languages. MIT Press, 1996.

[30] C. Morgan. Programming from Specifications, 2d. Ed. Prentice Hall, 1994.

[31] P.D. Mosses. Compiler generation using denotational semantics. In A. Mazurkiewicz, editor,
Mathematical Foundations of Computer Science, Lecture Notes in Computer Science 45, pages
436–441. Springer, Berlin, 1976.

[32] P.D. Mosses. Denotational semantics. In J. van Leeuwen, editor, Handbook of Theoretical
Computer Science, volume B, chapter 11, pages 575–632. Elsevier, 1990.

[33] S. Muchnick and N.D. Jones, editors. Program Flow Analysis: Theory and Applications.
Prentice-Hall, 1981.

[34] H. Riis Nielson and F. Nielson. Semantics with Applications, a formal introduction. Wiley
Professional Computing. John Wiley and Sons, 1992.

[35] T. Nipkow, L. Paulson, and M. Wenzel. Isabelle/HOL: A Proof Assistant for Higher-Order
Logic. Springer-Verlag, 2002.

[36] B. Nordström, K. Petersson, and J. Smith. Programming in Martin-Löf ’s Type Theory. Oxford,
1990.

[37] C.H.-L. Ong. Correspondence between operational and denotational semantics. In S. Abram-
sky, D. Gabbay, and T. Maibaum, editors, Handbook of Computer Science, Vol. 4. Oxford
Univ. Press, 1995.

[38] S. Owre, et al. PVS: Combining specification, proof checking, and model checking. In Proc.
CAV ’87, pages 411–414. Springer-Verlag, 1996.

[39] B. Pierce. Formal models/calculi of programming languages. In Allen Tucker, editor, CRC
Handbook of Computer Science and Engineering. CRC Press, Boca Raton, FL, 1996.

[40] B. Pierce. Types and Programming Languages. MIT Press, 2002.

[41] B. Pierce, et al. Software Foundations. Technical Re-

port http://www.cis.upenn.edu/∼bcpierce/sf, University of Pennsylvania, 2011.

[42] G.D. Plotkin. A structural approach to operational semantics. Technical Report FN-19,
DAIMI, Aarhus, Denmark, September 1981.

[43] J. Rees and W. Clinger. Revised3 report on the algorithmic language Scheme. SIGPLAN
Notices, 21:37–79, 1986.

[44] J. Reynolds. Definitional interpreters for higher-order programming languages. J. of Higher-

Order and Symbolic Computation, 11:363–397, 1998.

[45] D.A. Schmidt. Denotational Semantics: A Methodology for Language Development. Allyn and
Bacon, Inc., 1986.

[46] K. Slonneger and B. Kurtz. Formal Syntax and Semantics of Programming Languages: A
Laboratory-Based Approach. Addison-Wesley, Reading, MA, 1995.

19
[47] J.E. Stoy. Denotational Semantics. MIT Press, Cambridge, MA, 1977.

[48] R.D. Tennent. Semantics of Programming Languages. Prentice-Hall International, Englewood

Cliffs, New Jersey, 1991.

[49] D. van Dalen. Logic and Structure, 3d edition. Springer, Berlin, 1994.

[50] D.A. Watt. Programming Language Syntax and Semantics. Prentice-Hall International, En-
glewood Cliffs, New Jersey, 1991.

[51] G. Winskel. Formal Semantics of Programming Languages. MIT Press, Cambridge, MA, 1993.

7 Further Information

The best starting point for further reading is the comparative semantics text of Nielson and Nielson
[34], which thoroughly develops the topics in this chapter. See also the texts by Slonneger and
Kurtz[46] and Watt[50].
Operational semantics has a long history; modern introductions are Hennessey’s text [17] and
Plotkin’s report on structural operational semantics [42]. The principles of natural semantics are
documented by Kahn [23]. A good example of the interpreter-based approach to semantics is the
text by Friedman, Wand, and Haynes [13].
Mosses’s paper [32] is a useful introduction to denotational semantics; textbook-length treat-
ments include those by Schmidt [45], Stoy [47], Tennent [48], and Winskel [51]. Gunter’s text [15]
uses denotational-semantics-based mathematics to compare several of the semantics approaches.
Pierce [39] and Mitchell [29] provide foundational supporting material.
Of the many textbooks on axiomatic semantics, one might start with books by Dromey [11]
or Gries [14]; both emphasize precondition semantics, which is most effective at deriving correct
code. Apt’s paper [2] is an excellent description of the formal properties of relational semantics,
and Dikstra’s text [9] is the standard reference on precondition semantics. Hoare’s landmark papers
on relational semantics [19, 21] are worth reading as well. Many texts have been written on the
application of axiomatic semantics to systems development; two samples are by Jones [22] and
Morgan [30].
You are also urged to read the other chapters in Section 9 of this Volume.

20