Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Successfully reported this slideshow.

1,267 views

Published on

No Downloads

Total views

1,267

On SlideShare

0

From Embeds

0

Number of Embeds

9

Shares

0

Downloads

0

Comments

0

Likes

1

No embeds

No notes for slide

- 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. scientiﬁc 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 ﬁxed 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 reﬂect 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 functionsfunction addOne(x:int):int { return (x+1);} x↦x+1
- 16. Programs as functionsfunction 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 functionsfunction 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. Inﬁnity• Recursion introduces inﬁnity to the picture.• For programmers, inﬁnity is where the power lies.• For models, inﬁnity is where the problems lie.• We need some topology to interpret recursion: a recursive function is modelled as the limit of an inﬁnite 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 identiﬁers → 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 ﬁrst 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 togetherrequest request request request q x2 x+3 input output input output
- 29. Plugging togetherrequest request request request q x2 x+3 input output input output
- 30. Plugging together request request request requestq x2 x+3 input output input output
- 31. Plugging togetherrequest request request request x2 x+3 input output input output2
- 32. Plugging togetherrequest request request request x2 x+3 input output input output 2
- 33. Plugging togetherrequest request request request x2 x+3 input output input output 4
- 34. Plugging togetherrequest request request request x2 x+3 input output input output 4
- 35. Plugging togetherrequest request request request x2 x+3 input output input output 4
- 36. Plugging togetherrequest request request request x2 x+3 input output input output 7
- 37. Plugging togetherrequest request request request x2 x+3 input output input output 7
- 38. Plugging togetherrequest request q x2+3 input output
- 39. Plugging together request requestq x2+3 input output
- 40. Plugging togetherrequest request x2+3 input output2
- 41. Plugging togetherrequest request x2+3 input output 2
- 42. Plugging togetherrequest request x2+3 input output 7
- 43. Plugging togetherrequest 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 speciﬁes what moves are available and when they can be played.• Agent and environment take turns.
- 45. The integer game request environment 0 1 2 ... agentA game is a tree of moves. Child moves canonly be played once their parents have beenplayed.
- 46. and its dual request agent0 1 2 ... environment
- 47. int → int request request0 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 bycopying information.•It works for any game, with no knowledge ofthe 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 theoremTheorem [Abramsky-Jagadeesan-Malacaria 1993/2000; cf. Hyland-Ong,Nickau]Every pure functional program denotes ahistory-free strategy.Every computable history-free strategycan 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 cellwrite(true) ok read ...then what?A good memory location cannot be historyfree. But the right history-sensitive strategy isclear.
- 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 theoremTheorem [Abramsky-M]Every program of a certain imperativelanguage denotes a strategy.Every computable strategy can beprogrammed in this language.
- 68. Inﬁnity• Inﬁnity enters the games models because we have to allow moves to be repeated.
- 69. Inﬁnity• Inﬁnity enters the games models because we have to allow moves to be repeated.
- 70. Inﬁnity• Inﬁnity enters the games models because we have to allow moves to be repeated.
- 71. Inﬁnity• Inﬁnity 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 inﬁnity• We need inﬁnity to interpret recursion and loops.• But we can tame it too: • restrict to ﬁnite data sets • limit the ways moves can be repeated • ﬁnd out what programs are left
- 73. Towards automatedcorrectness checkingTheorem [Ghica-M]For a certain constrained class ofprograms, strategies are ﬁnite statemachines.Therefore, we can automatically checkwhether 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, Wingﬁeld].
- 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.ﬂickr.com/photos/loganwilliams/ • Tic Tac Toe http://www.ﬂickr.com/photos/anonymonk/ • Code http://www.ﬂickr.com/photos/circle_hk • Go http://www.ﬂickr.com/photos/spwelton/ • Lego http://www.ﬂickr.com/photos/kaptainkobold/ • Cat drinking http://www.ﬂickr.com/photos/meantux/ • Alan Turing http://www.ﬂickr.com/photos/sbisson/ • Blue Sky http://www.ﬂickr.com/photos/11247304@N06

No public clipboards found for this slide

Be the first to comment