Functional Reactive Programming

Headline

Lecture Functional Reactive Programming as part of Course:Lambdas in Koblenz

Functional Reactive Programming

Functional reactive programming is a general paradigm well suited to programming reactive systems in a high-level and functional way.

Reactive systems are those that handle continuous time-varying values, discrete events in real time, and react accordingly. A good example of these systems is a mobile robot. They must take into consideration continuous inputs like wheel speed, orientation, and discrete events such as detection of another object.

The class of reactive systems we're interested in here is interactive graphical UIs. A user interface has multiple components that can be seen as discrete events and continuous time-varying values. An input box, where one might write their name, is an example of a time varying value (it continously changes -- whenever the user types something); a button is an example of a discrete event in time: at certain points in time the user will click the button. This will make more sense with practice and code samples.

So the promise of functional reactive programming is that we can program these complicated reactive systems in a pure functional way. But how?

Functional Reactive Programming introduces two key concepts: Behaviours and Events.

1. Behaviours are first-class values that vary over continuous time. That means a behaviour is a value that changes with time and can be passed to/returned by functions.
2. Events are first-class values that occur at some points in time. They may refer, e.g., to happenings in the real world time -- such as a mouse click or a key press.

This type of wholemeal programming (working with the whole, not the individual part) is quite common in functional programming. When working with lists, the same pattern appears: we think and define functions in terms of entire lists, rather than about any particular element in the list.

Functional reactive programming just takes it further by abstracting over time itself.

In the end, the programmer doesn't need to worry about any of the how, just the what (which quite nicely aligns with the first paper on FRP (http://conal.net/papers/icfp97/icfp97.pdf), which distinguishes presentation from modelling). So, we manipulate time-dependent behaviours and events, but we never directly see the time.

In fact, both Behaviors and Events are usually abstract data types, meaning we don't even need to know how they are defined.

Later we'll see what this actually looks like.

Behaviors

A Behaviour is a first-class value that varies over continuous time. In other words, a Behaviour is a value that can be passed to and returned by functions (is first-class) and this value is defined for all time (and can change accross time)

Intuitively, it can be seen as a function from time to value (b :: Time -> Value) and could be visualized as:

Note how this function is pure (there are no side effects): we simply map all points in time to a value.

A behaviour is an abstract type constructor, meaning we know nothing about its data constructors. We interact with behaviours through the combinators and functions defined by the FRP implementation we're using. The type parameter of Behavior indicates the type of the values.

data Behavior a

Behaviors are usually Functors (it depends on the FRP implementation, in Reflex they are). We can imagine that if we have a behaviour (x :: Behavior Int) which is for all points in time equal to 1 (you might imagine the 2D graph of the constant math function f(x) = 1), there is an easy way to define a behavior y which is constantly equal to 2: fmap (+1) x :: Behavior Int.

Let's write a short example of a function that transforms a Behavior String into a Behavior (Maybe Color)

data Color = Yellow | Magenta | Cyan

color :: Behavior String -> Behavior (Maybe Color)
color bstr = fmap toColor bstr
  where
    toColor "yellow"  = Just Yellow
    toColor "magenta" = Just Magenta
    toColor "cyan"    = Just Cyan
    toColor _         = Nothing

An example of a behaviour we'll use is the value in an input text box. This box has a string at all times. Before the user writes anything, the value is the empty string. The value at some time after the user has written "123" is "123".

Events

An Event is a first-class value that occurs at discrete points in time. In other words, an Event is a value that can be passed to and returned by functions (is first-class) and this value is defined at only some points in time. We know if the event is occuring, and if it is, what its value is.

It's a bit harder to think about intuitively, but one can imagine an event as a function from time to maybe a value (e :: Time -> Maybe Value) or as a list of values and the times at which they occur (e :: [(Time, Value)]).

An event is also an abstract type constructor, meaning we know nothing about its data constructors. As with behaviors, we interact with events through the combinators and functions defined by the FRP implementation we're using. The type parameter of Event also indicates the type of the values.

data Event a

Above, a is the type of the value the event carries when it occurs.

Events are functors! You can think of them being functors the same way you would about Behaviors.

An example of an event we’ll use is the one generated by a button. Everytime the button is clicked, an event occurs of type Event () (a button click has no associated value, unlike, e.g., key presses, which would have type Event Char).

In Technology:Reflex we'll see how we can manipulate and put together events and behaviors to build a reactive application.

Technologies

• Technology:Reflex