Implementation challenges

Perhaps the most defining characteristic of classical FRP is the use of continuous time.

This means FRP assumes that signals are changing all the time, even if their value is still the same, leading to needless recomputation. For example, the mouse position signal will trigger updates to the application dependency graph—like the one we saw previously for the mean program—even when the mouse is stationary.

Another problem is that classical FRP is synchronous by default: events are processed in order, one at a time. Harmless at first, this can cause delays, which would render an application unresponsive should an event take substantially longer to process.

Paul Hudak and others furthered research on higher-order FRP [7] [8] to address these issues, but that came at the cost of expressivity.

The other formulations of FRP aim to overcome these implementation challenges.

Throughout the rest of the chapter, I'll be using signals and behaviors interchangeably.

First-order FRP

The most well-known reactive language in this category is Elm (see http://elm-lang.org/), an FRP language that compiles to JavaScript. It was created by Evan Czaplicki and presented in his paper Elm: Concurrent FRP for Functional GUIs [3].

Elm makes some significant changes to higher-order FRP.

It abandons the idea of continuous time and is entirely event-driven. As a result, it solves the problem of needless recomputation highlighted earlier. First-order FRP combines both behaviors and events into signals which, in contrast to higher-order FRP, are discrete.

Additionally, first-order FRP allows the programmer to specify when synchronous processing of events isn't necessary, preventing unnecessary processing delays.

Finally, Elm is a strict programming language—meaning arguments to functions are evaluated eagerly—and that is a conscious decision as it prevents space and time leaks, which are possible in a lazy language such as Haskell.

Tip

In an FRP library such as Fran, implemented in a lazy language, memory usage can grow unwieldy as computations are deferred to the absolutely last possible moment, therefore causing a space leak. These larger computations, accumulated over time due to laziness, can then cause unexpected delays when finally executed, causing time leaks.

Asynchronous data flow

Asynchronous Data Flow generally refers to frameworks such as Reactive Extensions (Rx), ReactiveCocoa, and Bacon.js. It is called as such as it completely eliminates synchronous updates.

These frameworks introduce the concept of Observable Sequences [4], sometimes called Event Streams.

This formulation of FRP has the advantage of not being confined to functional languages. Therefore, even imperative languages like Java can take advantage of this style of programming.

Arguably, these frameworks were responsible for the confusion around FRP terminology. Conal Elliott at some point suggested the term CES (see https://twitter.com/conal/status/468875014461468677).

I have since adopted this terminology (see http://vimeo.com/100688924) as I believe it highlights two important factors:

• A fundamental difference between CES and FRP: CES is entirely event-driven
• CES is highly composable via combinators, taking inspiration from FRP

CES is the main focus of this book.

Arrowized FRP

This is the last formulation we will look at. Arrowized FRP [5] introduces two main differences over higher-order FRP: it uses signal functions instead of signals and is built on top of John Hughes' Arrow combinators [6].

It is mostly about a different way of structuring code and can be implemented as a library. As an example, Elm supports Arrowized FRP via its Automaton (see https://github.com/evancz/automaton) library.

Tip

The first draft of this chapter grouped the different formulations of FRP under the broad categories of Continuous and Discrete FRP. Thanks to Evan Czaplicki's excellent talk Controlling Time and Space: understanding the many formulations of FRP (see https://www.youtube.com/watch?v=Agu6jipKfYw), I was able to borrow the more specific categories used here. These come in handy when discussing the different approaches to FRP.