RealTime FRP

1
Real-Time FRP

• Zhanyong Wan
• Yale University
• Department of Computer Science
• Joint work with
• Walid Taha
• Paul Hudak

2
Reactive Programming

• Reactive systems
• Continually react to stimuli
• Environment cannot wait system must respond
  quickly
  
• Run forever
• Reactive Languages
• Signal, Lustre, Esterel, Synchronous Kahn
  networks, Simulink, Modelica, and etc
  
• Functional Reactive Programming (FRP)
• Modern functional programming ideas

3
Functional Reactive Programming

• Functional Reactive Programming (FRP)
• High-level, declarative
• Continuous time domain
• Discrete time domain
• Recursion higher-order functions
• Originally embedded in Haskell
• Continuous/discrete signals
• Behaviors values varying over time
• Events discrete occurrences
• Reactivity b1 until ev - b2
• Combinators until, switch, when, integral, etc
• Applications animation, GUI, vision, robotics,
  etc
  

4
An example Thermostat

• The state diagram
• In FRP
• on_mode on until when (t high) -
  off_mode
  
• off_mode off until when (t
  on_mode
  
• thermostat on until start - on_mode

5
Crouching Robots, Hidden Camera

• RoboCup
• Team controllers written in FRP
• Embedded robot controllers written in C(our
  goal use FRP instead)

camera
Team B controller
Team A controller
radio
radio
6
FRP for Real-time Systems

• Real-time/embedded systems are a demanding
  setting
  
• For example, soccer-bots must respond quickly
• On-board micro-controller
• Very limited resources
• FRP does not guarantee resource bounds
• General recursion
• x integral (x 1) vs. x x 1
• Higher order functions/signals
• Can create new components at run time
• Can re-wire the system at run time
• Garbage collection
• Needs to be restricted!

7
Restricting FRP
All FRP programs
FRP
8
Our Goal
Real-Time FRP, a subset of FRP, with guaranteed
bounds on execution time and space, deadlock
free, and reasonably expressive (practical for
embedded systems).

• What is an operational semantics for FRP?
• How to reason about the cost of running a
  program?
  
• How do we make FRP run fast?
• How do we make guarantees about both time and
  space behavior?
  
• How do we draw the line between FRP and Haskell?

9
Real-Time FRP (RT-FRP)

• Reactive language base language
• Reactive language
• Space/time bounded
• Non-trivial two forms of recursion, etc
• Base language
• Any pure language where resource bound can be
  proved
  
• Examples suitable for real-time systems
• Bounded-size data types (tuples, arrays, etc.)
• Arithmetic (integers, floating-point numbers,
  etc.)
  
• Bounded iteration (map, fold, etc.)

10
Syntax of Reactive Language

• Syntax of signals
• Not intended for end user
• We can translate many FRP constructs into RT-FRP
  (see paper)
  
• let snapshot x ? s1 in s2 exports x to the base
  language
  
• ext e imports the result of e from the base
  language

11
Intuition for RT-FRP Continuations
set ? ? sequence

• RT-FRP continuations
• Finite number of continuations
• Events trigger invocation of continuations
• Between events, the behavior is continuous (s in
  s until ev k defines the continuous
  behavior)
  
• Can be viewed as hybrid automata
• Finite number of states
• Events trigger transitions between states
• Within one state, there is a behavior
• Can also be viewed as goto statements
• Continuations as labels
• No need for stack or heap

12
Example of Continuations

• Recall the thermostat in FRP
• on_mode on until when (t high) -
  off_mode
  
• off_mode off until when (t
  on_mode
  
• thermostat on until start - on_mode
• The same thermostat can be written in RT-FRPlet
  snapshot t ? temperature in
  
• let continue
• k1 _ (ext On) until when (ext (t high))
  k2
  
• k2 _ (ext Off) until when (ext (t
  k1
  
• in (ext On) until start k1
• What is different from FRP?
• Distinction between base language and reactive
  language
  
• Continuations can only be used in a safe
  manner
  
• Ensured by syntax and type system

13
Operational Semantics

• A program is just a signal
• 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
• where

14
Program Execution

• Each step terminates
• The run of a program never terminates.The
  programs meaning is the infinite sequence of
  values, or observations that it yields.
  
• The run of a program is defined as the
  sequence
  

15
Some Semantic Rules
16
What Can Go Wrong?

• Recursive signals
• Good expressive
• let snapshot x ? integral (ext (x 1)) in
• (the implementation of integral has a delay in
  it)
  
• Bad execution can get stuck
• let snapshot x ? ext (x 1) in
• Solution
• Use type system to disallow direct recursions,
  thus preventing deadlock
  
• Distinguishes what can be used now and what can
  only be used later
  
• Ensures that at least one delay appears somewhere
  in a recursive signal
  
• Inspired by multi-level languages

17
What Can Go Wrong? (contd)

• Recursive continuations
• Good adds expressive power
• Bad term size can grow
• Solution
• Restrict by syntax and type system
• Inspired by tail recursion

18
Types

• Base language types g
• Contexts
• Distinguishes variables that can be used now and
  that cannot.
  
• Judgments e is a base language term of type
  g s is a signal carrying values of type g

Annotated types ?g ?g g
x is an immediate variable (can be used now)
x ?g x is a later variable (can be used onl
y later) x g
19
Some Typing Rules
where b is a base type (i.e. does not have a
functional part)
Promote( )/demote( )
20
Key Results

• Assuming that similar properties hold in the base
  language
  
• Type preservation
• Thus no core dumps!
• Environment and term size cannot exceed a bound
• We can actually derive the bound s
• Thus no space leaks!
• Using a type system, progress is guaranteed
• Thus no deadlocks!
• In addition, each step takes bounded amount of
  time
  
• Thus no missed deadlines!

21
Future Work on RT-FRP

• Enrich language for practical use
• Compile into lower-level code (C, etc.)
• Consider embedded systems
• Test case compile to PIC micro-controller on our
  soccer-bots
  
• Arrows Hughes as model for composing RT-FRP
  machines
  
• Multi-clock systems