**Taxonomy of FRP**

**Evan Czaplicki**

Signal Graphs

n : Signal Int

n = count Mouse.clicks

Mouse.position : Signal (Int,Int)

Prezi / elm-lang.org

m = count Mouse.clicks

n = m

?

Inputs

Nodes

lift : (a -> b) -> Signal a -> Signal b

lift2 : (a -> b -> c) -> Signal a -> Signal b -> Signal c

foldp : (a -> b -> b) -> b -> Signal a -> Signal b

Inputs

Transform

State

Functional Reactive Programming

Signal graphs are dynamic

Inputs can be created at any time

No equational reasoning

flatMap : Signal a -> (a -> Signal b) -> Signal b

Pure

Monadic FRP

n : Signal Int

n = count Mouse.clicks

m = count Mouse.clicks

n = m

bind : Signal a -> (a -> Signal b) -> Signal b

Applicative FRP

Disallow flatMap, bind, join

join : Signal (Signal a) -> Signal a

Signals "start" when the program starts

Memory must grow linearly with time!

Signal graphs are static

All inputs are created at startup

n : Signal Int

n = count Mouse.clicks

m = count Mouse.clicks

n ≠ m

Impure

Monadic FRP

join : Signal (Signal a) -> Signal a

n : Signal Int

n = count Mouse.clicks

m = count Mouse.clicks

n = m

Arrowized FRP

Explicitly model signal nodes!

pure : (a -> b) -> Automaton a b

n : Signal Int

n = count Mouse.clicks

m = count Mouse.clicks

n = m

Flapjax

FrTime

Reactive Extensions

Bacon.js

Elm

Real-Time FRP

Event-Driven FRP

state : b -> (a -> b -> b) -> Automaton a b

Stop modeling

input nodes!

step : a -> Automaton a b -> (Automaton a b, b)

loop : s -> Automaton (a,s) (b,s) -> Automaton a b

Yampa

Netwire

Automaton (in Elm)

in Elm

Signal a = Automaton World a

Dynamic Signals

Static Signals

Dynamic Signal Graphs