This post continues from “Reactive values from the future” and “Reactive normal form”.

Fran/FRP reactive behaviors could change continuously, while reactive values change only discretely. The Reactive library keeps continuity orthogonal to reactivity. To combine continuity and reactivity, simply compose reactivity with a non-reactive type of functions of time.

One could literally use Reactive (Time -> a), but Reactive also includes a more optimizable version as the module Data.Fun. The denotation of Fun t a is simply t -> a, but it has a constructor (K) for constant-valued functions, which occur frequently.

data Fun t a = K a | Fun (t -> a)

As with the other types in Reactive, most of the operations on Fun values are in the form of instances of standard type classes, specifically Monoid, Functor, Applicative, Monad, and Arrow. As an example of optimization,

instance Functor (Fun t) where
  fmap f (K   a) = K   (f a)
  fmap f (Fun g) = Fun (f.g)

Data.Reactive defines reactive behaviors very simply as a type composition of Reactive and Fun Time:

type Time = Double

type ReactiveB = Reactive :. Fun Time

Wrapping the combination in a type composition (g :. f) gives Functor and Applicative instances for reactive behaviors that combine the corresponding instances for Reactive and Fun Time.

Combining reactive values and non-reactive functions in this way, we can create implementations that mix data-driven (push) and demand-driven (pull) evaluation. The reactive value part is data-driven, resulting in a time function. That time function can then be polled until a new time function is pushed for further polling. As an important optimization, only poll when the time function is really time-varying (made with the Fun constructor). If it’s constant (made with K), then output the value just once and wait until the next push.

I’m not sure whether this elegant composition of orthogonal notions is really a good idea in practice. A benefit is the extra static typing and ability to use of the two types independently. A drawback is that the operations on reactive values have to be rewrapped and perhaps tweaked for convenient use directly on reactive behaviors.

The post “Reactive values from the future” presented a simple formulation of functional events and reactive values, built on a functional notion of future values. In the current post, I’ll describe some of the implementation of events and reactive values*.

Reactive values

Switching

As mentioned previously, the stepper function corresponds directly to the representation of Reactive.

data Reactive a = Stepper a (Event a)

stepper :: a -> Event a -> Reactive a
stepper = Stepper

The representation of all other functions must therefore produce their result in terms of stepper, which thereby serves as a kind of reactive normal form (RNF). The implementation can be understood as a set of rewrite rules that convert arbitrary reactive expressions into RNF. (These rewrite rules are all provably correct based on a simple semantics of events and reactive values.)

The more general switching form can be expressed in terms of switcher and (monadic) join:

switcher :: Reactive a -> Event (Reactive a) -> Reactive a
r `switcher` er = join (r `stepper` er)

We’ll see below how to reduce join to a stepper.

Functor

As a simple example, fmap f applies a function f to a reactive value pointwise, which is equivalent to applying f to the initial value and to each occurrence value.

instance Functor Reactive where
  fmap f (a `Stepper` e) = f a `stepper` fmap f e

The Event functor is also easily defined. Recall that an event is a future reactive value:

newtype Event = Future (Reactive a)

We want to map a given function over that reactive value, which we can do by combining fmap on Future with fmap on Reactive.

instance Functor Event where
  fmap f (Event fut) = Event ((fmap.fmap) f fut)

Applicative

The Functor definitions for Reactive and Event are straightforward, because the Stepper structure is easily preserved. A more challenging case is Applicative.

instance Applicative Reactive where ... 

First the easy part. A pure value a becomes reactive by using a as the initial value and mempty as the (never-occuring) change event:

  pure a = a `stepper` mempty

Consider next applying a reactive function to a reactive argument:

  rf@(f `Stepper` Event futf) <*> rx@(x `Stepper` Event futx) =
    f x `stepper` Event fut
   where ...

The initial value is f x, and the change event occurs each time either the function or the argument changes. If the function changes first, we will (in the future) apply a new reactive function to an old argument:

           fmap ( rf' -> rf' <*> rx) futf

Similarly, if the argument changes first, we will apply an old reactive function and a new argument:

           fmap ( rx' -> rf <*> rx') futx

Combining these two futures as alternatives:

...
     fut = fmap ( rf' -> rf' <*> rx ) futf `mappend`
           fmap ( rx' -> rf  <*> rx') futx

A wonderful thing about this (<*>) definition for Reactive is that it automatically caches the previous value of the function or argument when the argument or function changes. This caching property is especially handy in nested applications of (<*>), which can arise either explicitly or through liftA2, liftA3, etc. Consider u == liftA2 f r s or, equivalently, u == pure f <*> r <*> s, where r and s are reactive values, with initial values r0 and s0, respectively. (The (<*>) operator is associates to the left.) The initial value u0 of u is f r0 s0. If r changes from r0 to r1, then the new value of pure f <*> r will be f r1, which then gets applied to s0, i.e., u1 == f r1 s0. However, if instead s changes from s0 to s1, then u1 == f r0 s1. In this latter case, the old value f r0 of pure f <*> r is passed on without having to be recomputed. The savings is significant for functions that do some work based partial applications.

Monad

Above we saw a simple definition of switcher:

r `switcher` er = join (r `stepper` er)

How does join work for Reactive? Rather than using the standard definition of join in terms of (>>=), let’s do the reverse:

r >>= h = joinR (fmap h r)

where joinR is join for reactive values:

joinR :: Reactive (Reactive a) -> Reactive a

Defining joinR is similar to (<*>) above. For a reactive-reactive value rr, either rr or the reactive value that is the initial value of rr changes first.

joinR ((a `Stepper` Event fut) `Stepper` e'@(Event fut')) =
  a `stepper` Event fut''
 where
   -- If fut  arrives first, switch and continue waiting for e'.
   -- If fut' arrives first, abandon fut and keep switching with new
   -- reactive values from fut'.
   fut'' = fmap (`switcher` e') fut `mappend` fmap join fut'

Dynamic optimization

Operations on events and reactive values dynamically re-optimize themselves. For instance, the reactive value fmap f r is known to quiesce (stop changing) when r quiesces, which is knowable because futures have a special representation for the future that never comes. (Really, only easy common cases are optimized. An example of a hard-to-detect never-occuring event would be filtering out first the odd numbers and then the even numbers from an Int-valued event.) Similarly, the reactive value liftA2 f r s quiesces once both r and s quiesce. Once reactive values quiesce, no more computational resource is devoted to them.

Events

The definitions above are mainly for reactive values. What about functional events?

Monoid

Events form a monoid: mempty is the never-occurring event, which is represented by the never-occuring future, while e `mempty` e' is an event consisting of all occurrences from e and e'.

instance Monoid (Event a) where
  mempty  = Event mempty
  Event fut `mappend` Event fut' = Event (fut `merge` fut')

This merge operation combines two Future streams into one.

merge :: Future (Reactive a) -> Future (Reactive a) -> Future (Reactive a)
Never `merge` fut   = fut
fut   `merge` Never = fut
u     `merge` v     =
  (onFut (`merge` v) <$> u) `mappend` (onFut (u `merge`) <$> v)
 where
   onFut f (a `Stepper` Event t') = a `stepper` Event (f t')

The mappend used in the definition of merge is from Future. It picks the earlier future and abandons the other. Thus the first of the two events to occur will contribute an occurrence value (a), leaving a residual event, which is combined with the not-yet-occurring event.

Applicative and Monad

The Applicative and Monad instances for events are like those for lists, and unlike those for reactive values (given above). For instance, the occurrences of ef <*> ex consist of f x for all occurrences f of ef and occurrences x of ex. See the source code for details.

Conclusion

I’m happy with the simplicity of this new functional formulation of events and reactive values. While most previous FRP implementations used polling, Reactive is change-driven and so has the can be much more efficient. It also uses a dynamically self-optimizing representation.

I’ve gotten interested lately in revisiting functional reactive programming (FRP). I was never entirely satisfied with the semantics or implementation in my original Fran formulation or in its successors. Over the last year, I’ve enjoyed getting more interface and functionality from standard type classes, and I’ve realized that quite a lot of FRP could be both packaged and implemented by leveraging those classes. This post describes that packaging, and in particular shows how the Monad interface makes some operations very easy to define. I suspect that monadic functional reactivity is a very powerful structuring tool with lovely applications.

At ICFP 07, I had a conversation with Mike Sperber about FRP and about his FRP-based Lula system for stage lighting. Mike used blocking threads in Lula, which I had never considered for FRP. While playing with the idea, I realized that I could give a very elegant and efficient solution to caching, unlike my previous FRP implementations, including the recent DataDriven library. From there, I stumbled on the idea of reactive normal form and separating out an aspect of reactivity into the notion of future values. A third new (to me) idea is to factor out continuity from reactivity, so that reactive behaviors arise by composing orthogonal notions of reactive values and non-reactive functions of continuous time.

Two previous posts presented future values, first describing interface and semantics and then a multi-threaded implementation. This post builds a simple foundation for FRP on top of future values, as part of a library Reactive.

Functional events and reactive values

A functional event is (semantically) a stream of time-associated values, ordered with respect to time. For example, the stream of keystrokes you’ll type. While many systems have a primitive notion of events, functional events are compositional, i.e., they’re constructed by applying operations to one or more simpler events, e.g., the lower-case version of your keystroke stream, the substream of uppercase keys, or the temporally interleaved stream from your keystrokes and mine (data massaging, filtering, and merging). As usual, compositionality leads to reuse.

A reactive value is a functional notion for a value that changes discretely over time, based on the occurrences of one or more (possibly composite) events. Reactive values provide a a first class encapsulation of the infinite time-line of varying values. As such, they replace many of the uses of imperative programming, particularly concurrent imperative programming, which is notoriously difficult to work with and reason about.

The semantics of a reactive value can be simply a function of time. Since reactive values change discretely (though see below for continuous change), their meanings will be step functions (changing only at a discrete–but possibly infinite–set of domain values). Since a step function is fully defined by an initial value and a discrete set of time-associated values (the changes), we can represent reactive values as a value plus an event that yields more values over time.

data Reactive a = Stepper a (Event a)

How then might we define Event? It is a stream of a first occurrence and some more occurrences, just like Reactive. But the first occurrence and the remainder event are knowable only in the future. Therefore,

newtype Event a = Future (Reactive a)

using the Future type described in a previous post.

Composing reactivity

Standard classes

Many of the means of constructing events and reactive values are packaged as methods on the standard type classes Monoid, Functor, Applicative, and Monad. See the Reactive wiki page and documentation for descriptions of these instances. Here are a few examples:

• The event e `mappend` e' occurs whenever e or e' occurs.
• The event fmap f e (also called f <$> e) occurs with value f x whenever e occurs with value x.
• The reactive value rf <*> rx at time t is equal has value f x, where rf and rx have the values f and x respectively at time t. The (<*>) and pure functions (the methods of Applicative) are the basis of applying an n-ary function to n reactive values, to form a reactive value. Note the implicit and semantically simple concurrency.
• If ee is an event-valued event (ee :: Event (Event a)), then join ee is an event whose occurrences are all of the occurrences of all of the events in ee.

Switching

The main tools for introducing reactivity are stepper and switcher. (These combinators were added to Fran after the original paper, which had only single-shot events and therefore encouraged an explictly recursive programming style.) The stepper function exactly corresponds to the Stepper constructor in our our new representation of Reactive above.

stepper :: a -> Event a -> Reactive a
stepper = Stepper

For a more general reactive combinator, switcher takes an initial reactive value and an event that generates reactive values to switch to.

switcher :: Reactive a -> Event (Reactive a) -> Reactive a

Pleasantly, it is very easy to define this general form of switching in terms of the simpler stepper. To see how this definition works, note that the arguments of switcher are also suitable as arguments to stepper, but the result will be of type Reactive (Reactive a) instead of Reactive a. Fortunately, Reactive is a monad, so join turns reactive-reactive values into reactive values.

r `switcher` er = join (r `stepper` er)

Other building blocks

Many other event and reactive value combinators are described in the Reactive library docs. Here are just a few:

• Cumulative application of functions from a function-valued event.
• A scanl for events and one for values.
• Filtering of Maybe-valued events, and filtering of an event by a boolean reactive value.
• Sampling of a reactive value at each occurrence of an event.

Coming attractions

Future posts will (a) present the implementation of events and reactive values via a reactive normal form, and (b) say how to blend temporal continuity with our discrete notion of reactive values.

I see FRP as being a viable alternative to imperative programming, especially with concurrency. Like the imperative programming model, FRP is about change. Unlike concurrent imperative programming, FRP has formally tractable–even simple–semantics. Future blog posts will give examples of how to reduce dependence on side-effects, widening the pure, and hence semantically tractable and composable, core of programs.

Edit 2008-02-07: added missing type parameter in Event definition.