After informally reviewing the main concepts from game semantics and placing the development of the field in a historical context we examine its main applications. We focus in particular on finite state model checking, higher order model checking and more recent developments in hardware design.
Chronology, methodology, ideologyGame Semantics is a denotational semantics in the conventional sense: for any term, it assigns a certain mathematical object as its meaning, which is constructed compositionally from the meanings of its sub-terms in a way that is independent of the operational semantics of the object language. What makes Game Semantics particular, peculiar maybe, is that the mathematical objects it operates with are not sets and functions, as the reader familiar with denotational semantics in the tradition of Scott and Strachey might expect [81].To understand how Game Semantics works it is perhaps easiest to start with the fundamental notion of observable action: the simplest kind of event that a program, or term in general, can be involved in (as producer or consumer) during the course of its execution. For example, the program that interacts with its environment in the simplest possible form can be implicated in two events: starting execution and finishing it. If we construe the notions of input and output broadly enough, the former is an input and the latter is an output. Then, from this point of view there can only be two semantically distinct behaviours of this kind, one that starts then finishes, and one that starts and does not finish. A marginally more complex interaction would be the case of a program that computes a boolean value for which it must be able to produce two distinguishable results. In this class of programs we should be able to find three distinct behaviours, associated with the following three sequences of observable actions: start · true, start · false, start.The idea of observable action can be extended to programs of higher-order type, inductively on the structure of the type. The observable actions of a function are those of the function body and those of its arguments. For example, a (call-by-name) function of type (bool × bool) → bool has nine observable actions. They are the three distinct actions for boolean programs taken thrice, once for each argument and once for the result. Let us tag argument actions with a1 and a2 and result actions with r to prevent confusion. The set of possible behaviours is richer now, including for example interactions such asBoth interactions above represent a computation in which a function starts executing, evaluates one of the arguments, then the other, then produces a result. In both cases the arguments produce true, as does the function. However, these two interactions arise in two semantically distinct functions, which evaluate their arguments in different orders.In a programming language with side-effects it is of course relevant in what precise order a function evaluates its arguments. And modelling a (program) function as a sched...