1. Sept 4, 2001ICFP, Florence, Italy 1 Real-Time FRP Zhanyong Wan Yale University Department of Computer Science Joint work with: Walid Taha Paul Hudak

2. Sept 4, 2001 ICFP, Florence, Italy2 Outline  To be written

3. Sept 4, 2001 ICFP, Florence, Italy3 Reactive Programming  Reactive systems Continually reacts to stimuli Environment cannot wait  Reactive Languages Signal: programming by constraints Lustre: synchronous data-flow Esterel: imperative Simulink: visual but lacks control structure Synchronous Kahn networks: extends Lustre w/ recursion FRP (Functional Reactive Programming): synchronous data-flow + (higher-order, typed) functional programming

4. Sept 4, 2001 ICFP, Florence, Italy4 Functional Reactive Programming  Functional Reactive Programming (FRP) General framework for reactive programming High-level, declarative Time is continuous Embedded in Haskell  Behaviors  Events  Reaction  Combinators

5. Sept 4, 2001 ICFP, Florence, Italy5 Behaviors  Continuous behaviors capture any time-varying quantity, whether: input (sonar, temperature, video, etc.), output (actuator voltage, velocity vector, etc.), or intermediate values internal to a program.  Operations on behaviors include: Generic operations such as arithmetic, integration, and differentiation. Domain-specific operations such as edge-detection and filtering for vision, scaling and rotation for animation and graphics, etc.

6. Sept 4, 2001 ICFP, Florence, Italy6 Events  Discrete event streams include user input as well as domain- specific sensors, asynchronous messages, interrupts, etc.  They also include tests for dynamic constraints on behaviors (temperature too high, level too low, etc.)  Operations on event streams include: Mapping, filtering, reduction (?), etc. Reactive behavior modification (next slide).

7. Sept 4, 2001 ICFP, Florence, Italy7 Reactive Control of Continuous Values One animation example that demonstrates key aspects of FRP: growFlower = stretch size flower where size = 1 + integral bSign bSign = 0 `until` (lbp ==> -1 `until` lbp ==> bSign).|. (rbp ==> 1 `until` rbp ==> bSign)

8. Sept 4, 2001 ICFP, Florence, Italy8 Applications of FRP  Fran is a DSL for graphics and animation.  Frob is a DSL for robotics.  FranTk and Fruit are two DSL’s for graphical user interfaces.  FVision is a DSL for vision.  FRP is the essence of Fran, Frob, FranTk, Fruit, and FVision: Fran= FRP + graphics engine + library Frob= FRP + robot controller + library FranTk= FRP + Tk substrate + library Fruit= FRP + Java 2D substrate + library FVision= FRP + XVision + library

9. Sept 4, 2001 ICFP, Florence, Italy9 FVision Fran Frob FranTk Fruit Domain-Specific Languages Functional Programming FRP Functions, types, etc. (Haskell) Continuous behaviors and discrete reactivity Specialized languages Graphics, Robotics, GUIs, VisionApplications

10. Sept 4, 2001 ICFP, Florence, Italy10 Crouching Robots, Hidden Camera  RoboCup Two teams of soccer-playing robots, color- marked for ID/orientation Overhead camera is the only sensor camera radio Team B ctrlr Team A ctrlr

11. Sept 4, 2001 ICFP, Florence, Italy11 Yale RoboCup Team  FRP used in all parts of the system: FVision for sensing Frob for robot controlling E-FRP (on-going work) for the on-board micro- controller

12. Sept 4, 2001 ICFP, Florence, Italy12 The Problem  FRP cannot guarantee bound on space/time Program can diverge Program can take unreasonable amount of time to respond to a stimulus Program can use huge amount of memory Program can have hard-to-find space leaks  Goal: to extend FRP for real-time applications

13. Sept 4, 2001 ICFP, Florence, Italy13 Our Goal  How do we make FRP run fast?  How do we make guarantees about both time and space behavior?  How does FRP relate to other models of hybrid automata?  Can FRP be used for embedded systems?  And at a more abstract level: What is an operational semantics for FRP? Our goal: Real-Time FRP, a subset of FRP, with guaranteed bounds on execution time and space, and deadlock free.

14. Sept 4, 2001 ICFP, Florence, Italy14 Real-Time FRP (RT-FRP)  Reactive language + base language  Reactive language Expressive: two forms of recursion Space bounded Time bounded  Base language Can be instantiated to any resource-bounded language

15. Sept 4, 2001 ICFP, Florence, Italy15 Syntax of Base Language  Syntax of the sample base language: (“lifted” terms are just “Maybe” type)  Syntax of values in the sample base language:

16. Sept 4, 2001 ICFP, Florence, Italy16 Syntax of Reactive Language  Syntax of signals:  let-signal exports to the base language  ext imports from the base language Note: “Event a” in FRP is isomorphic to “Behavior (Maybe a)”. In RT-FRP we just combine them and call them “signals”.

17. Sept 4, 2001 ICFP, Florence, Italy17 Operational Semantics  A program is executed in discrete steps, driven by time- stamped input values. Given a time t and input i, a term s evaluates to a value v and is updated to a new term s ’.  We write this as: and or, more compactly as: where:

18. Sept 4, 2001 ICFP, Florence, Italy18 Program Execution  A proper RT-FRP program never terminates. Its meaning is the infinite sequence of values, or “observations” that it yields.  The sequence: s 0  v 1, s 1 ; s 1  v 2, s 2 ; s 2  v 3, s 3 ; …  Meta-comment: Program output depends on the time-stamped input pairs (t j,i j ). t 0,i 0 t 2,i 2 t 1,i 1

19. Sept 4, 2001 ICFP, Florence, Italy19 Some Semantic Rules

20. Sept 4, 2001 ICFP, Florence, Italy20 Snapshot  Recursion form #1: recursive signal

21. Sept 4, 2001 ICFP, Florence, Italy21 Swtich  Delayed switching  Allows self-reacting signals let snapshot x  s 1 switch on (when (x>100)) in s 2 …

22. Sept 4, 2001 ICFP, Florence, Italy22 Continuation  Delayed switching too  Recursion form #2: tail signals

23. Sept 4, 2001 ICFP, Florence, Italy23 Intuition for Continuation  Hybrid automaton Continuations are modes s in “s until k j >” defines the behavior within a mode  Goto statement Continuations are labels No need for stack

24. Sept 4, 2001 ICFP, Florence, Italy24 For Example  A simple model of a thermostat: let snapshot temp  let continue k1 () = until when (temp>t) => k2 k2 () = until when (temp k1 in t0 until startev => k1 in ext temp

25. Sept 4, 2001 ICFP, Florence, Italy25 From FRP to RT-FRP  Many FRP constructs can be expressed in RT-FRP as macros Lifting When

26. Sept 4, 2001 ICFP, Florence, Italy26 More from FRP to RT-FRP  How about integral? the forward-Euler method:  And etc.

27. Sept 4, 2001 ICFP, Florence, Italy27 What Can Go Wrong?  Recursive signals Expressive However, w/ recursion, term can get stuck immediately: let snapshot x  ext x in … Or get stuck after updating: let snapshot f  delay id (ext (\y. f y)) in …  let snapshot f  delay (\y. f y) (ext (\y. f y)) in …  Solution: Use type system to disallow “direct” recursions, thus preventing “deadlock” Ensures delay/switch/until appear somewhere in a recursive signal Restricts delay to non-functional types

28. Sept 4, 2001 ICFP, Florence, Italy28 What Can Go Wrong? (cont’d)  Tail signals Adds expressive power However, w/ tail signals, term size can grow let continue { k x = f (s until ev => k) } in (s until ev => k)  let continue { k x = f (s until ev => k) } in f (s until ev => k)  let continue { k x = f (s until ev => k) } in f (f (s until ev => k)) … There are other ways for a term to grow  Solution Restrict by syntax and type system Inspired by tail recursion

29. Sept 4, 2001 ICFP, Florence, Italy29 Types  Syntax of types  Annotated types: Local/exportable: /  Contexts  Expose( )/export( )  Judgments: “e is a base language term of type g” “s is a signal carrying values of type g”

30. Sept 4, 2001 ICFP, Florence, Italy30 Some Typing Rules Where b is a base (non-functional) type:

31. Sept 4, 2001 ICFP, Florence, Italy31 Some Typing Rules Where b is a base (non-functional) type:

32. Sept 4, 2001 ICFP, Florence, Italy32 More typing rules  Let-continue:  until:

33. Sept 4, 2001 ICFP, Florence, Italy33 More typing rules  Let-continue:  until:

34. Sept 4, 2001 ICFP, Florence, Italy34 Key Results  Type safety / preservation thus no core dumps!  Each step takes bounded amount of time thus no time leaks!  Term size cannot exceed a bound thus no space leaks!  In addition, using a type system, progress is guaranteed thus no deadlock!

35. Sept 4, 2001 ICFP, Florence, Italy35 Future Work on RT-FRP  Enrich language for practical use.  Compile into lower-level code (C, etc.).  Examine sensor / behavior fusion.  Consider embedded systems.  Better formulation of well-formed recursion.  Test case: compile to PIC micro-controller on our “soccer-bots”.