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

This means that 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 this chapter, I'll be using the terms signals and behaviors interchangeably.

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, which was 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 the synchronous processing of events isn't necessary, preventing unnecessary processing delays.

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

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 such as 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.

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.