Slides from Guy McCusker's Inaugural Lecture at the University of Bath, 25 April 2012. A brief introduction to game semantics of programming languages.

1. Programs as Strategies

2. Programs as Strategies

3. Computers and
software are...
• Important
• Ubiquitous
• Complicated

4. Layers of complexity
• Programs
• Compilers
• Operating System
• Hardware
• ... and that’s just on one
computer.

5. The usual answer:
models
• The “layers” are already
abstractions.
• They encapsulate parts
of the system and
interact with the rest via
reduced interfaces.
• We don’t understand
the whole truth - just a
model.

6. Two models of drinking
from a tap
• I turn on the tap and I
get a drink

7. Two models of drinking
from a tap
• Turning the tap opens a
valve which releases
water supplied at a
pressure of 2 bar...

8. Models and
abstractions
• Our conceptual models and their
corresponding abstractions make complex
systems tractable.
• Really good models (e.g. scientific theories)
help us predict, design, and discover.
• What models will help us with
programming?

9. Turing machines
• Alan Turing devised an
early model of
computation: the Turing
Machine.
• A TM manipulates data
stored on a tape
according to a table of
rules - a fixed program.

10. Turing machines
• Turing machines expose powerful and
central concepts:
• computability
• time usage
• space usage
• But they are monolithic, and too low-level
to be of use in analysing modern software.

11. Goal: compositionality
• Software is built by assembling small pieces
of code into large programs.
• Our models should reflect and empower
this compositionality.
• We need abstractions that support
composition.

12. Functions
• Possibly the most widely used (mathematical) abstraction.
• We can happily plug functions together:
• 2x
• sin(x)
• sin(2x)
• x2
• sin(2x) + x2
• These are all functions of type (R→R)

13. Understanding +
• The + in the last example operates on two
functions to give another function
sin(2x) + x 2
• So + has the type
(R→R) ⨉ (R→R) → (R→R)

14. Higher-order functions
and programming
• These higher order functions provide both a
mathematical model of programming and
an approach to programming itself.
• higher-order functional programming
began with LISP in the 1950s.

15. Programs as functions
function addOne(x:int):int {
return (x+1);
}
x↦x+1

16. Programs as functions
function fact(x:int):int {
if (x == 0) return 1
else return (x * fact(x-1));
}
x ↦ x!
3↦3⨉2 ⨉1=6
but why?

17. Programs as functions
function fact(x:int):int {
if (x == 0) return 1
else return (x * fact(x-1));
}
x ↦ x!
3↦3⨉2 ⨉1=6
but why?

18. Infinity
• Recursion introduces infinity to the picture.
• For programmers, infinity is where the power
lies.
• For models, infinity is where the problems lie.
• We need some topology to interpret
recursion: a recursive function is modelled as
the limit of an infinite sequence of
approximants.

19. Imperative programs?
function fact(x:int):int {
y := x;
z := 1;
while (y ≠ 0) {
z := z ⨉ y;
y := y-1;
}
return z;
}

20. Modelling memory
• Code like
y := y-1
manipulates (an abstraction of) the memory
of the computer.
• To model these with functions, we need to
model the memory itself as a function
identifiers → values.

21. Mathematical semantics
• These ideas were the basis of mathematical
semantics developed by Strachey, Scott and
others from around 1970.
• The theory provides:
• an understanding of recursion and loops
• ways of proving certain correctness
properties of programs (e.g. Hoare logic)

22. But
• For imperative programs, the theory breaks
abstractions: functions can manipulate the
memory in arbitrary ways.
• There is no way to see the two factorial
programs as “the same.”

23. A different abstraction:
interaction
• Replace functions with interacting agents.
• An agent is a “black box” that receives
messages from its environment and sends
out responses.
• Ideas like these were first used in modelling
concurrent systems (Hoare’s CSP, Milner’s
CCS) around 1980.

24. Functions as agents
input output

25. Functions as agents
input output
•That was easy!

26. Functions as agents
input output
•That was easy!
•It turns out to be more convenient to add a
“request” protocol at the beginning.

27. Functions as agents
request request
input output
•That was easy!
•It turns out to be more convenient to add a
“request” protocol at the beginning.

28. Plugging together
request request request request
q
x2 x+3
input output input output

29. Plugging together
request request request request
q
x2 x+3
input output input output

30. Plugging together
request request request request
q
x2 x+3
input output input output

31. Plugging together
request request request request
x2 x+3
input output input output
2

32. Plugging together
request request request request
x2 x+3
input output input output
2

33. Plugging together
request request request request
x2 x+3
input output input output
4

34. Plugging together
request request request request
x2 x+3
input output input output
4

35. Plugging together
request request request request
x2 x+3
input output input output
4

36. Plugging together
request request request request
x2 x+3
input output input output
7

37. Plugging together
request request request request
x2 x+3
input output input output
7

38. Plugging together
request request
q
x2+3
input output

39. Plugging together
request request
q
x2+3
input output

40. Plugging together
request request
x2+3
input output
2

41. Plugging together
request request
x2+3
input output
2

42. Plugging together
request request
x2+3
input output
7

43. Plugging together
request request
x2+3
input output
7

44. A formalisation: game
semantics
• This idea can be made precise in lots of
ways. Here’s one.
• Interaction is the playing of a game between
the agent and its environment.
• The game specifies what moves are available
and when they can be played.
• Agent and environment take turns.

45. The integer game
request environment
0 1 2 ... agent
A game is a tree of moves. Child moves can
only be played once their parents have been
played.

46. and its dual
request agent
0 1 2 ... environment

47. int → int
request request
0 1 2 ... 0 1 2 ...

48. Strategies
• Our “agents” are strategies: plans telling the
agent what to do in any given situation.

49. The identity function
request request
0 1 2 ... 0 1 2 ...

50. The identity function
request request
0 1 2 ... 0 1 2 ...

51. The identity function
request request
0 1 2 ... 0 1 2 ...

52. The identity function
request request
0 1 2 ... 0 1 2 ...

53. The identity function
request request
0 1 2 ... 0 1 2 ...

54. The identity function
request request
0 1 2 ... 0 1 2 ...
•This strategy implements the function x ↦ x by
copying information.
•It works for any game, with no knowledge of
the moves: pure logic.

55. History-free strategies
• Every strategy we have seen so far chooses
its move based only on the last move by
the environment.
• Notice: history-freeness is preserved by
plugging.

56. A new theory
• These ideas form game semantics.
• Games models possess a lot of the
mathematical structure from the function-
based semantics:
• compositionality,
• recursion as a limit of approximants, etc.
• But also...

57. A theorem
Theorem [Abramsky-Jagadeesan-
Malacaria 1993/2000; cf. Hyland-Ong,
Nickau]
Every pure functional program denotes a
history-free strategy.
Every computable history-free strategy
can be programmed.

58. Imperative programs
• Imperative programs work by interacting
with the computer’s memory.
• Idea: model a memory location as an agent.
write(true) write(false) read
ok ok true false

59. Interacting with the
memory
write(true)
cell

60. Interacting with the
memory
write(true)
cell

61. Interacting with the
memory
cell
ok

62. Interacting with the
memory
cell
ok

63. Interacting with the
memory
read
cell

64. Interacting with the
memory
read
cell

65. Interacting with the
memory
read
cell
write(true) ok read ...then what?
A good memory location cannot be history
free. But the right history-sensitive strategy is
clear.

66. Extending the theory
• The theory of game semantics extends to
arbitrary history-sensitive strategies.
• Then the cell can respond appropriately to
read moves, so we can model the memory.
• Hence...

67. Another theorem
Theorem [Abramsky-M]
Every program of a certain imperative
language denotes a strategy.
Every computable strategy can be
programmed in this language.

68. Infinity
• Infinity enters the games models because
we have to allow moves to be repeated.

69. Infinity
• Infinity enters the games models because
we have to allow moves to be repeated.

70. Infinity
• Infinity enters the games models because
we have to allow moves to be repeated.

71. Infinity
• Infinity enters the games models because
we have to allow moves to be repeated.
• As usual, this is where all the technical
problems are.

72. Taming infinity
• We need infinity to interpret recursion and
loops.
• But we can tame it too:
• restrict to finite data sets
• limit the ways moves can be repeated
• find out what programs are left

73. Towards automated
correctness checking
Theorem [Ghica-M]
For a certain constrained class of
programs, strategies are finite state
machines.
Therefore, we can automatically check
whether two such programs are equal.

74. More
• Lots of other kinds of games to model other
kinds of programs, logic, ... [numerous authors]
• Implementation of strategies as circuits [Ghica]
• Logical counterparts of history-sensitive
strategies [Churchill, Laird, M]
• Relational and geometrical foundations of
game semantics [Calderon, M, Power,
Wingfield].

75. Further
• Modelling the whole
system - all layers,
multiple computers,
people?
• Quantitative models?
Power consumption,
transmission and storage
costs, ...

76. Legal bits
• Photographs used under Creative Commons Attribution-
NonCommercial-ShareAlike licence:
• Circuit Board http://www.flickr.com/photos/loganwilliams/
• Tic Tac Toe http://www.flickr.com/photos/anonymonk/
• Code http://www.flickr.com/photos/circle_hk
• Go http://www.flickr.com/photos/spwelton/
• Lego http://www.flickr.com/photos/kaptainkobold/
• Cat drinking http://www.flickr.com/photos/meantux/
• Alan Turing http://www.flickr.com/photos/sbisson/
• Blue Sky http://www.flickr.com/photos/11247304@N06