Theodore Norvell NDEV Take Back Control Or How I Learned to Stop Worrying and Love Event Driven Code 1 What other people are saying about this talk: ● “[...] our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.” --- E.W.Dijkstra 2 The Problem ● Problem: How to write event driven code in a structured fashion. 3 Outline ● Event driven programs ● Structured vs unstructured control structures ● Some ideas I had ● TBC: a monad-based library to solve the problem 4 McMillan's warning ● When asked what sort of thing is most likely to blow a program off course, Harald McMillan would have said Events, dear boy, events! 5 Events ● In a GUI: User actions such as keypresses, mouse actions, button clicks, focus, blur, etc. ● In a server: Requests from clients. Responses from DBMSs. ● In a client: Responses from servers. ● In a real-time system: The passage of time ● In a concurrent or distributed program: Receiving messages. ● In a concurrent program: Semaphore changes state. 6 A use case Use case: Greet the user forever 0 The following sequence is repeated forever 0.0 System: Prompts for name 0.1 User: Types in a name and presses “enter” 0.2 System: Greets the user by name The Use case tells a story. 7 A non-event-driven program proc main() loop print “What is your name?” var name := readLine print “Hello, ” name “.” The code tells a story. The structure of the story is reflected in the structure of the code. 8 An event-driven program var nameBox := new TextField() var question := new Label( “What is your name” ) var reply := new Label() proc main() nameBox.on(enter, nameBoxHandler) show question show nameBox show reply proc nameBoxHandler() var name := nameBox.contents() reply.text := “Hello, ” name “.” Where did the control structure go? 9 Narrative structure The structure of the non-event-driven code follows the narrative of the use case Use case: Greet the user forever 0 The following sequence is proc main() repeated forever loop print “What is your 0.0 System: Prompts for name?” name var name := readLine 0.1 User: Types in a print “Hello, ” name “.” name and presses “enter” 0.2 System: Greets the user by name 10 Unstructured Use case: Greet ... var nameBox := new TextField var question := new Label( “W 0 The following sequence is var reply := new Label() repeated forever proc main() 0.0 System: Prompts for nameBox.on(enter,nameBo name show question 0.1 User: Types in a show nameBox name and presses show reply “enter” 0.2 System: Greets the proc nameBoxHandler() user by name var name := nameBox.conte reply.text := “Hello, ” name “.” 11 Changing requirements Use case: Greet the user forever proc main() 0 The following sequence is loop repeated forever print “What is your name?” 0.0 System: Prompts for var name := readLine name print “Hello, ” name “.” 0.1 User: Types in a name and presses pause 1000 “enter” 0.2 System: Greets the user by name 0.3 Wait 1 second 12 Changing requirements var nameBox := new TextField() var question := new Label( “What's your name” ) var reply := new Label() var timer := new Timer() proc main() nameBox.on(enter,nameBoxHander) timer.on( done, timeHander ) show question ; show nameBox ; show reply proc nameBoxHandler() var name := nameBox.contents reply.text := “Hello, ” name “.” hide question ; hide nameBox ; start timer proc timeHandler() stop timer ; show question ; clear nameBox ; show nameBox 13 Protocol ● A prefix-closed set of sequences of events. ● What formalisms do we have for describing sets of sequences? – State machines (Σ, Q, q , T) 0 – Regular Expressions – Context Free Grammars (BNF) – Extended Context Free Grammar (EBNF) ECFG = CFG + RE 14 Some broad opinions ● State Machines ● CFGs – Unstructured – Limited structure (Not compositional) – Abstraction (naming). – No abstraction – Recursion – No recursion ● Extended CFGs ● Regular expressions – Structuring – Structured: loop, choice, sequence – Abstraction – No abstraction. No – Recursion recursion. 15 Digression on unstructured and structured programming ● 1948: Konrad Zuse publishes a paper on Plankalkül, a structured programming language – No one reads it. ● 1948: Von Neumann and Goldstein introduce “flow diagrams” in Planning and Coding of Problems for an Electronic Computing instrument – Everyone reads it. ● 1948: Coding is in machine language with branch instructions or conditional branch instructions (at best!). 16 Plankalkül vs Flow Diagrams 17 Digression on unstructured and structured programming ● 1953: Wheeler (re)invents the subroutine. ● 1958: Flow chart are the state of the art. – Coding is in assembly or Fortran II (computed go to) ● 1958--1960: Algol 58, Algol 60, and LISP provide structured control constructs if-then-else, while-do, for-do ● 1968: ACM Curriculum Committee recommends flowcharts in the first course of computer science programs. – Fortran IV and COBOL are dominant languages 18 Digression on unstructured and structured programming From Knuth's CACM paper on RUNCIBLE. 19 Digression on unstructured and structured programming ● 1967: Floyd's paper on verification of flowcharts ● 1968: Dijkstra pens his “GO TO statement considered harmful”, sparking in the Structured Programming Revolution. – “The go to statement as it stands is just too primitive; it is too much an invitation to make a mess of one's program.” ● 1969: Hoare's paper on verification of structured programs ● 1978: The revolution is mostly over. Most programmers are taught to only use GOTOs to emulate “structured code”. – Popular languages include Fortran IV and Pascal ● 1988: Flowcharts and unstructured programming are dead. 20 Digression on unstructured and structured programming ● 1998-2018 Flowcharts are popular in comic strips, but not in software engineering. – Unstructured code is not well regarded – Most popular languages (JavaScript, Java, Python) don't even have a go to statement. 21 Back to Events ● Inversion of control programs are state machines ● and state machines are just unstructured programming all over again. ● Worse than that, the representation of state is often entirely implicit. – Consider the program we just saw. – It has two states. How are these states represented? – Only the transitions are explicitly represented. 22 Inv. of control ~= State machine var nameBox := new TextField() var question := new Label( “What's your name” ) var reply := new Label() var timer := new Timer() show question timer.done / stop timer show nameBox show question show reply clear nameBox show nameBox nameBox.enter / var name := nameBox.contents reply.text := “Hello, ” name “.” hide question hide nameBox ; start timer 23 Non-inverted control ~= ECFGs var nameBox := new TextField() var question := new Label( “What's your name” ) var reply := new Label() <main> ::= show nameBox ; show question; show reply <main loop> <main loop> ::= ( clear nameBox show question show nameBox <get and show reply> hide question hide nameBox pause 1000 )* <get and show reply> ::= await nameBox.enter var name := nameBox.contents reply.text := “Hello, ” name “.” 24 An early idea ● Background: A “parser generator” translates grammars (annotated with actions) to non-event-driven driven code in an implementation language. (E.g., yacc, ANTLR, JavaCC, etc.) ● Problem: How to write UI code cleanly ● Solution 0: – Design user interfaces using grammars annotated with actions – We need a “UI generator” to generate UI code from annotated grammars. 25 Parser combinators ● An alternative to parser generators is “parser combinators”. ● A parser combinator is a function that takes one or more parsers and produces a parser. ● Parser combinator libraries allow us to write recursive descent parsers directly in the implementation language but which look like the EBNF grammar. ● EDSL (Embedded Domain Specific Language) 26 Parser combinators ● Example: – <A> → b <C> | d <E> is coded as function A() : Parser { return alt( tok(“b”).seq(C), tok(“d”).seq(E) ) ; } ● Here are the key library routines: ● tok makes a parser from a terminal ● alt(p,q) is a parser where p and q are parsers ● p.seq(f) is a parser where p is a parser and f returns a parser. 27 A better idea ● Problem: How can we write UI code cleanly ● Solution 1: – Use a library of combinators – to write code directly in the implementation language – but which looks a lot like a grammar. 28 A personal note ● In 1992 I went to a summer school in Germany ● Phil Wadler was giving lectures on Monads ● I asked him about a problem I was having structuring a parser in a pure functional language. ● His advice: Use a monad ● This has often proved good advice. 29 Can we use a Monad? ● Yes! ● Monadic Parser Combinators are a well known style of Parser Combinator. ● Monads work well with parsers because they help move information around both implicitly and explicitly. ● But what is a monad? 30 What is a Monad? ● Each monad M is a generic type with two operations – unit is a function that maps each A to an M<A> – p.bind(f) is an M<A> when p is an M<B> and f is a function that maps each B to an M<A> – With some laws similar to the monoid laws. 1. p.bind(unit) = p 2. unit(a).bind(f) = f(a) 3. (p.bind(f)).bind(g) = p.bind(λx∙f(x).bind(g)) 31 Monads are useful ● Monads are used for implicit state, exceptions, I/O, collections,