An earlier post introduced functional future values, which are values that cannot be known until the future, but can be manipulated in the present. That post presented a simple denotational semantics of future values as time/value pairs. With a little care in the definition of Time (using the Max monoid), the instances of Functor, Applicative, Monad are all derived automatically.

A follow-up post gave an implementation of Future values via multi threading. Unfortunately, that implementation did not necessarily satisfy the semantics, because it allowed the nondeterminism of thread scheduling to leak through. Although the implementation is usually correct, I wasn’t satisfied.

After a while, I hit upon an idea that really tickled me. My original simple semantics could indeed serve as a correct and workable implementation if I used a subtler form of time that could reveal partial information. Implementing this subtler form of time turned out to be quite tricky, and was my original motivation for the unamb operator described in the paper Push-pull functional reactive programming and the post Functional concurrency with unambiguous choice.

It took me several days of doodling, pacing outside, and talking to myself before the idea for unamb broke through. Like many of my favorite ideas, it’s simple and obvious in retrospect: to remove the ambiguity of nondeterministic choice (as in the amb operator), restrict its use to values that are equal when non-bottom. Whenever we have two different methods of answering the same question (or possibly failing), we can use unamb to try them both. Failures (errors or non-termination) are no problem in this context. A more powerful variation on unamb is the least upper bound operator lub, as described in Merging partial values.

I’ve been having trouble with the unamb implementation. When two (compatible) computations race, the loser gets killed so as to free up cycles that are no longer needed. My first few implementations, however, did not recursively terminate other threads spawned in service of abandoned computations (from nested use of unamb). I raised this problem in Smarter termination for thread racing, which suggested some better definitions. In the course of several helpful reader comments, some problems with my definitions were addressed, particularly in regard to blocking and unblocking exceptions. None of these definitions so far has done the trick reliably, and now it looks like there is a bug in the GHC run-time system. I hope the bug (if there is one) will be fixed soon, because I’m seeing more & more how unamb and lub can make functional programming even more modular (just as laziness does, as explained by John Hughes in Why Functional Programming Matters).

I started playing with future values and unambiguous choice as a way to implement Reactive, a library for functional reactive programming (FRP). (See Reactive values from the future and Push-pull functional reactive programming.) Over the last few days, I’ve given some thought to ways to implement future values without unambiguous choice. This post describes one such alternative.

Edits:

• 2010-08-25: Replaced references to Simply efficient functional reactivity with Push-pull functional reactive programming. The latter paper supercedes the former.
• 2010-08-25: Fixed the unFuture field of FutureG to be TryFuture.

Futures, presently

The current Future type is just a time and a value, wrapped in a a newtype:

newtype FutureG t a = Future (Time t, a)
  deriving (Functor, Applicative, Monad)

Where the Time type is defined via the Max monoid. The derived instances have exactly the intended meaning for futures, as explained in the post Future values and the paper Push-pull functional reactive programming. The “G” in the name FutureG refers to generalized over time types.

Note that Future is parameterized over both time and value. Originally, I intended this definition as a denotational semantics of future values, but I realized that it could be a workable implementation with a lazy enough t. In particular, the times have to reveal lower bounds and allow comparisons before they’re fully known.

Warren Burton explored an applicable notion in the 1980s, which he called “improving values”, having a concurrent implementation but deterministic functional semantics. (See the paper Encapsulating nondeterminacy in an abstract data type with deterministic semantics or the paper Indeterminate behavior with determinate semantics in parallel programs. I haven’t found a freely-available online copy of either.) I adapted Warren’s idea and gave it an implementation via unamb.

Another operation finds the earlier of two futures. This operation has an identity and is associative, so I wrapped it up as a Monoid instance:

instance (Ord t, Bounded t) => Monoid (FutureG t a) where
  mempty = Future (maxBound, undefined)
  Future (s,a) `mappend` Future (t,b) =
    Future (s `min` t, if s <= t then a else b)

This mappend definition could be written more simply:

  u@(Future (t,_)) `mappend` u'@(Future (t',_)) =
    if t <= t' then u else u'

However, the less simple version has more potential for laziness. The time type might allow yielding partial information about a minimum before both of its arguments are fully known, which is the case with improving values.

Futures as functions

The Reactive library uses futures to define and implement reactivity, i.e., behaviors specified piecewise. Simplifying away the notion of events for now,

until :: BehaviorG t a -> FutureG t (BehaviorG t a) -> BehaviorG t a

The semantics (but not implementation) of BehaviorG is given by

at :: BehaviorG t a -> (t -> a)

The semantics of until:

(b `until` Future (t',b')) `at` t = b'' `at` t
 where
   b'' = if t <= t' then b else b'

FRP (multi-occurrence) events are then built on top of future values, and reactivity on top of until.

The semantics of until shows what information we need from futures: given a time t, we need to know whether t is later than the future’s time and, if so, what the future’s value is. For other purposes, we’ll also want to know the future’s time, but again, only once we’re past that time. We might, therefore, represent futures as a function that gives exactly this information. I’ll call this function representation “function futures” and use the prefix “S” to distinguish the original “simple” futures from these function futures.

type TryFuture t a = Time t -> Maybe (S.FutureG t a)

tryFuture :: F.FutureG t a -> TryFuture t a

Given a probe time, tryFuture gives Nothing if the time is before or at the future’s time, or Just u otherwise, where u is the simple future.

We could represent F.FutureG simply as TryFuture:

type F.FutureG = TryFuture  -- first try

But then we’d be stuck with the Functor and Applicative instances for functions instead of futures. Adding a newtype fixes that problem:

newtype FutureG t a = Future { unFuture :: TryFuture t a } -- second try

With this representation we can easily construct and try out function futures:

future :: TryFuture t a -> FutureG t a
future = Future

tryFuture :: FutureG t a -> TryFuture t a
tryFuture = unFuture

I like to define helpers for working inside representations:

inFuture  :: (TryFuture t a -> TryFuture t' a')
          -> (FutureG   t a -> FutureG   t' a')

inFuture2 :: (TryFuture t a -> TryFuture t' a' -> TryFuture t'' a'')
          -> (FutureG   t a -> FutureG   t' a' -> FutureG   t'' a'')

The definitions of these helpers are very simple with the ideas from Prettier functions for wrapping and wrapping and a lovely notation from Matt Hellige’s Pointless fun.

inFuture  = unFuture ~> Future

inFuture2 = unFuture ~> inFuture 

(~>) :: (a' -> a) -> (b -> b') -> ((a -> b) -> (a' -> b'))
g ~> h = result h . argument g

These helpers make for some easy definitions in the style of Semantic editor combinators:

instance Functor (FutureG t) where
  fmap = inFuture.fmap.fmap.fmap

instance (Bounded t, Ord t) => Applicative (FutureG t) where
  pure  = Future . pure.pure.pure
  (<*>) = (inFuture2.liftA2.liftA2) (<*>)

Type composition

These Functor and Applicative instances (for FutureG t) may look mysterious, but they have a common and inevitable form. Every type whose representation is the (semantic and representational) composition of three functors has this style of Functor instance, and similarly for Applicative.

Instead of repeating this common pattern, let’s make the type composition explicit, using Control.Compose from the TypeCompose library:

type FutureG t = (->) (Time t) :. Maybe :. S.FutureG t  -- actual definition

Now we can throw out inFuture, inFuture2, (~>), and the Functor and Applicative instances. These instances follow from the general instances for type composition.

Monoid

The Monoid instance could also come automatically from type composition:

instance Monoid (g (f a)) => Monoid ((g :. f) a) where
  { mempty = O mempty; mappend = inO2 mappend }

The O here is just the newtype constructor for (:.), and the inO2 function is similar to inFuture2 above.

However, there is another often-useful Monoid instance:

-- standard Monoid instance for Applicative applied to Monoid
instance (Applicative (g :. f), Monoid a) => Monoid ((g :. f) a) where
  { mempty = pure mempty; mappend = liftA2 mappend }

Because these two instances “overlap” are are both useful, neither one is declared in the general case. Instead, specialized instances are declared where needed, e.g.,

instance (Ord t, Bounded t) => Monoid (FutureG t a) where
  mempty  = (  O .  O ) mempty   -- or future mempty
  mappend = (inO2.inO2) mappend

How does the Monoid instance work? Start with mempty. Expanding:

mempty

  == {- definition -} 

O (O mempty)

  == {- mempty on functions -}

O (O (const mempty))

  == {- mempty on Maybe -}

O (O (const Nothing))

So, given any probe time, the empty (never-occurring) future says that it does not occur before the probe time.

Next, mappend:

O (O f) `mappend` O (O f')

  == {- mappend on FutureG -}

O (O (f `mappend` f'))

  == {- mappend on functions -}

O (O ( t -> f t `mappend` f' t))

  == {- mappend on Maybe -}

O (O ( t -> f t `mappendMb` f' t))
  where
    Nothing `mappendMb` mb'    = mb'
    mb `mappendMb` Nothing     = mb
    Just u `mappendMb` Just u' = Just (u `mappend` u')

The mappend in this last line is on simple futures, as defined above, examining the (now known) times and choosing the earlier future. Previously, I took special care in that mappend definition to enable min to produce information before knowing whether t <= t'. However, with this new approach to futures, I expect to use simple (flat) times, so it could instead be

u@(Future (s,_)) `mappend` u'@(Future (s',_)) = if s <= s' then u else u'

or

u `mappend` u' = if futTime u <= futTime u' then u else u'

futTime (Future (t,_)) = t

or just

mappend = minBy futTime

How does mappend work on function futures? Given a test time t, if both future times are at least t, then the combined future’s time is at least t (yielding Nothing). If either future is before t and the other isn’t, then the combined future is the same as the one before t. If both futures are before t, then the combined future is the earlier one. Exactly the desired semantics!

Relating function futures and simple futures

The function-based representation of futures relates closely to the simple representation. Let’s make this relationship explcit by defining mappings between them:

sToF :: Ord t => S.FutureG t a -> F.FutureG t a

fToS :: Ord t => F.FutureG t a -> S.FutureG t a

The first one is easy:

sToF u@(S.Future (t, _)) =
  future ( t' -> if t' <= t then Nothing else Just u)

The reverse mapping, fToS, is trickier and is only defined on the image (codomain) of sToF. I think it can be defined mathematically but not computationally. There are two cases: either the function always returns Nothing, or there is at least one t for which it returns a Just. If the former, then the simple future is mempty, which is S.Future (maxBound, undefined). If the latter, then there is only one such Just, and the simple future is the one in that Just. Together, (sToF, fToS) form a projection-embedding pair.

We won’t really have to implement or invoke these functions. Instead, they serve to further specify the type F.FutureG and the correctness of operations on it. The representation of F.FutureG as given allows many values that do not correspond to futures. To eliminate these representations, require an invariant that a function future must be the result of applying sToF to some simple future.

We’ll require that each operation preserves this invariant. However, let’s prove something stronger, namely that operations on on F.FutureG correspond precisely to the same operations on S.FutureG, via sToF. In other words, sToF preserves the shape of the operations on futures. For type classes, these correspondences are the type class morphisms. For instance, sToF is a Monoid morphism:

sToF mempty == mempty

sToF (u `mappend` u') == sToF u `mappend` sToF u'

Caching futures

This function representation eliminates the need for tricky times (using improving values and unamb), but it loses the caching benefit that lazy functional programming affords to non-function representations. Now let’s reclaim that benefit. The trick is to exploit the restriction that every function future must be (semantically) the image of a simple future under sToF.

Examining the definition of sToF, we can deduce the following monotonicity properties of (legitimate) function futures:

• If the probe function yields Nothing for some t', then it yields Nothing for earlier times.
• If the probe function yields Just u for some t', then it yields Just u for all later times.

We can exploit these monotonicity properties by caching information as we learn it. Caching of this sort is what distinguishes call-by-need from call-by-name and allows lazy evaluation to work efficiently for data representations.

Specifically, let’s save a best-known lower bound for the future time and the simple future when known. Since the lower bound may get modified a few times, I’ll use a SampleVar (thread-safe rewritable variable). The simple future will be discovered only once, so I’ll use an IVar. I’ll keep the function-future for probing when the cached information is not sufficient to answer a query.

Prefix this caching version with a “C”, to distinguish it from function futures (“F”) and the simple futures (“S”):

data C.FutureG t a =
  Future (SampleVar t) (IVar (S.FutureG t a)) (F.FutureG t a)

Either the simple future or the function future will be useful, so we could replace the second two fields with a single one:

data C.FutureG t a =
  Future (SampleVar t) (MVar (Either (F.FutureG t a) (FF.FutureG t a)))

We’ll have to be careful about multiple independent discoveries of the same simple future, which would correspond to multiple writes IVar with the same value. (I imagine there are related mechanics in the GHC RTS for two threads evaluating the same thunk that would be helpful to understand.) I guess I could use a SampleVar and just not worry about multiple writes, since they’d be equivalent. For now, use the IVar version.

The caching representation relates to the function representation by means of two functions:

dToF :: Ord     t => C.FutureG t a -> F.FutureG t a

fToD :: Bounded t => F.FutureG t a -> C.FutureG t a

The implementation

dToF (C.Future tv uv uf) =
  F.Future $  t' -> unsafePerformIO $
    do mb <- tryReadIVar uv
       case mb of
         j@(Just (S.Future (Max t,_))) ->
           return (if t' <= t then Nothing else j)
         Nothing        ->
           do tlo <- readSampleVar tv
              if t' <= tlo then
                 return Nothing
               else
                 do let mb' = F.unFuture uf t'
                    writeIVarMaybe uv mb'
                    return mb'

-- Perhaps write to an IVar
writeIVarMaybe :: IVar a -> Maybe a -> IO ()
writeIVarMaybe v = maybe (return ()) (writeIVar v)

fToD uf = unsafePerformIO $
          do tv <- newSampleVar t0
             uv <- newIVar
             writeIVarMaybe uv (F.unFuture uf t0)
             return (Future tv uv uf)
 where
   t0 = minBound

It’ll be handy to delegate operations to F.Future:

inF :: (Ord t, Bounded t') =>
       (F.FutureG t a -> F.FutureG t' a')
    -> (  FutureG t a ->   FutureG t' a')
inF = dToF ~> fToD

inF2 :: (Ord t, Bounded t', Ord t', Bounded t'') =>
        (F.FutureG t a -> F.FutureG t' a' -> F.FutureG t'' a'')
     -> (  FutureG t a ->   FutureG t' a' ->   FutureG t'' a'')
inF2 = dToF ~> inF

Then

instance (Ord t, Bounded t) => Monoid (FutureG t a) where
  mempty  = fToD mempty
  mappend = inF2 mappend

instance (Ord t, Bounded t) => Functor     (FutureG t) where
  fmap = inF . fmap

instance (Ord t, Bounded t) => Applicative (FutureG t) where
  pure  = fToD . pure
  (<*>) = inF2 (<*>)

Wrap-up

Well, that’s the idea. I’ve gotten as far as type-checking the code in this post, but I haven’t yet tried running it.

What interests me most above is the use of unsafePerformIO here while preserving referential transparency, thanks to the invariant on F.FutureG (and the consequent monotonicity property). The heart of lazy evaluation of pure functional programs is just such an update, replacing a thunk with its weak head normal form (whnf). What general principles can we construct that allow us to use efficient, destructive updating and still have referential transparency? The important thing above seems to be the careful definition of an abstract interface such that the effect of state updates is semantically invisible through the interface.

I submitted a paper Simply efficient functional reactivity to ICFP 2008.

Abstract:

Functional reactive programming (FRP) has simple and powerful semantics, but has resisted efficient implementation. In particular, most past implementations have used demand-driven sampling, which accommodates FRP’s continuous time semantics and fits well with the nature of functional programming. Consequently, values are wastefully recomputed even when inputs don’t change, and reaction latency can be as high as the sampling period.

This paper presents a way to implement FRP that combines data- and demand-driven evaluation, in which values are recomputed only when necessary, and reactions are nearly instantaneous. The implementation is rooted in a new simple formulation of FRP and its semantics and so is easy to understand and reason about.

On the road to efficiency and simplicity, we’ll meet some old friends (monoids, functors, applicative functors, monads, morphisms, and improving values) and make some new friends (functional future values, reactive normal form, and concurrent “unambiguous choice”).

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.

Future values

A previous post described future values (or simply “futures”), which are values depend on information from the future, e.g., from the real world. There I gave a simple denotational semantics for future values as time/value pairs. This post describes the multi-threaded implementation of futures in Reactive‘s Data.Reactive module.

A simple representation

Futures are represented as actions that deliver a value. These actions are required to yield the same answer every time. Having a special representation for the future that never arrives (mempty) will allow for some very important optimizations later.

data Future a = Future (IO a) | Never

A value can be “forced” from a future. If the value isn’t yet available, forcing will block.

force :: Future a -> IO a
force (Future io) = io
force Never       = hang  -- block forever

Threads and synchronization

The current implementation of futures uses Concurrent Haskell‘s forkIO (fork a thread) and MVars (synchronized communication variables).

Except for trivial futures (pure/return and mempty), the action in a future will simply be reading an MVar. Internal to the implementation:

newFuture :: IO (Future a, a -> IO ())
newFuture = do v <- newEmptyMVar
               return (Future (readMVar v), putMVar v)

The MVar is written to as the final step of a forked thread. Importantly, it is to be written only once. (It’s really an IVar.)

future :: IO a -> Future a
future mka = unsafePerformIO $
             do (fut,sink) <- newFuture
                forkIO $ mka >>= sink
                return fut

Note that the actual value is computed just once, and is accessed cheaply.

Functor, Applicative, and Monad

The Functor, Applicative, and Monad instances are defined easily in terms of future and the corresponding instances for IO:

instance Functor Future where
  fmap f (Future get) = future (fmap f get)
  fmap _ Never        = Never

instance Applicative Future where
  pure a                      = Future (pure a)
  Future getf <*> Future getx = future (getf <*> getx)
  _           <*> _           = Never

instance Monad Future where
  return            = pure
  Future geta >>= h = future (geta >>= force . h)
  Never       >>= _ = Never

Monoid — racing

The remaining class to implement is Monoid. The mempty method is Never. The mappend method is to select the earlier of two futures, which is implemented by having the two futures race to extrat a value:

instance Monoid (Future a) where
  mempty  = Never
  mappend = race

race :: Future a -> Future a -> Future a

Racing is easy in the case either is Never:

Never `race` b     = b
a     `race` Never = a

Otherwise, spin a thread for each future. The winner kills the loser.

a `race` b = unsafePerformIO $
             do (c,sink) <- newFuture
                let run fut tid = forkIO $ do x <- force fut
                                              killThread tid
                                              sink x
                mdo ta <- run a tb
                    tb <- run b ta
                    return ()
                return c

The problem

This last piece of the implementation can fall short of the semantics. For a `mappend` b, we might get b instead of a even if they’re available simultaneously. It’s even possible to get the later of the two if they’re nearly simultaneous.

Edit (2008-02-02): although simultaneous physical events are extremely unlikely, futures are compositional, so it’s easy to construct two distinct but simultaneous futures in terms of on a common physical future.

What will it take to get deterministic semantics for a `mappend` b? Here’s an idea: include an explicit time in a future. When one future happens with a time t, query whether the other one occurs by the same time. What does it take to support this query operation?

A simpler implementation

In this implementation, futures (other than Never) hold actions that typically read an MVar that is written only once. They could instead simply hold lazy values.

data Future a = Future a | Never

Forcing a future evaluates to weak head normal form (WHNF).

force :: Future a -> IO a
force (Future a) = a `seq` return a
force Never      = hang

Making new future would work almost identically, just adding an unsafePerformIO.

newFuture :: IO (Future a, a -> IO ())
newFuture = 
  do v <- newEmptyMVar
     return (Future (unsafePerformIO $ readMVar v), putMVar v)

The Functor, Applicative, and Monad instances simplify considerably, using function application directly, instead of the corresponding methods from the Functor, Applicative, and Monad instances of IO.

instance Functor Future where
  fmap f (Future a) = Future (f a)
  fmap _ Never      = Never

instance Applicative Future where
  pure a                = Future a
  Future f <*> Future x = Future (f x)
  _        <*> _        = Never

instance Monad Future where
  return         = pure
  Future a >>= h = h a
  Never    >>= _ = Never

The Monoid instance is completely unchanged.

How does this implementation compare with the one above?

• It’s simpler, as stated.
• It’s a bit more efficient. Each MVar is only read once. Also, the Functor, Applicative, and Monad instances no longer create threads and MVars.
• The type statically enforces that forcing a future always gives the same result.
• Forcing a future reduces the value to WHNF and so is probably a little less lazy than the implementation above.

I’ve tried out this implementation and found that it intermittently crashes some examples that work fine in the IO version. I have no idea why, and I’d be very interested in ideas about it or anything else in this post.

A future value (or simply “future”) is a value that might not be knowable until a later time, such as “the value of the next key you press”, or “the value of LambdaPix stock at noon next Monday” (both from the time you first read this sentence), or “how many tries it will take me to blow out all the candles on my next birthday cake”. Unlike an imperative computation, each future has a unique value — although you probably cannot yet know what that value is. I’ve implemented this notion of futures as part of a library Reactive.

Edits:

• 2008-04-04: tweaked tag; removed first section heading.

You can force a future, which makes you wait (block) until its value is knowable. Meanwhile, what kinds of things can you do a future now?

• Apply a function to the not-yet-known value, resulting in another future. For instance, suppose fc :: Future Char is the first character you type after a specific time. Then fmap toUpper fc :: Future Char is the capitalized version of the future character. Thus, Future is a functor. The resulting future is knowable when fc is knowable.
• What about combining two or more future values? For instance, how many days between the first time after the start of 2008 that the temperature exceeds 80 degrees Fahrenheit at (a) my home and (b) your home. Each of those dates is a future value, and so is the difference between them. If those futures are m80, y80 :: Day, then the difference is diff80 = liftA2 (-) m80 y80. That difference is becomes knowable when the later of the m80 and y80 becomes knowable. So Future is an applicative functor (AF), and one can apply a future function to a future argument to get a future result (futRes = futFun <*> futArg). The other AF method is pure :: a -> Future a, which makes a future value that is always knowable to be a given value.
• Sometimes questions about the future are staged, such as “What will be the price of milk the day after it the temperature next drops below freezing” (plus specifics about where and starting when). Suppose priceOn :: Day -> Future Price gives the price of milk on a given day (at some specified place), and nextFreeze :: Day -> Future Day is the first date of a freeze (also at a specified place) after a given date. Then our query is expressed as nextFreeze today >>= priceOn, which has type Future Price. Future is thus a monad. (The return method of a monad is the same as the pure method of an AF.) From another perspective on monads, we can collapse a future future into a future, using join :: Future (Future a) -> Future a.

These three ways of manipulating futures are all focused on the value of futures. There is one more, very useful, combining operation that focuses on the timing of futures: given two futures, which one comes first. Although we can’t know the answer now, we can ask the question now and get a future. For example, what is the next character that either you or I will type? Call those characters mc, yc :: Future Char. The earlier of the two is mc `mappend` yc, which has type Future Char. Thus, Future ty is a monoid for every type ty. The other monoid method is mempty (the identity for mappend), which is the future that never happens.

Why aren’t futures just lazy values?

If futures were just lazy values, then we wouldn’t have to use pure, fmap, (<*>) (and liftA_n_), and (>>=). However, there isn’t enough semantic content in a plain-old-value to determine which of two values is earlier (mappend on futures).

A semantics for futures

To clarify my thinking about future values, I’d like to have a simple and precise denotational semantics and then an implementation that is faithful to the semantics. The module Data.SFuture provides such a semantics, although the implementation in Data.Future is not completely faithful.

The model

The semantic model is very simple: (the meaning of) a future value is just a time/value pair. The particular choice of “time” type is not important, as long as it is ordered.

newtype Future t a = Future (Time t, a)
  deriving (Functor, Applicative, Monad, Show)

Delightfully, almost all required functionality comes automatically from the derived class instances, thanks to the standard instances for pairs and the definition of Time, given below. Rather than require our time type to be bounded, we can easily add bounds to an arbitrary type. Rather than defining Time t now, let’s discover the definition while considering the required meanings of the class instances. The definition will use just a bit of wrapping around the type t, demonstrating a principle Conor McBride expressed as “types don’t just contain data, types explain data”.

Functor

The Functor instance is provided entirely by the standard instance for pairs:

instance Functor ((,) a) where fmap f (a,b) = (a, f b)

In particular, fmap f (Future (t,b)) == Future t (f b), as desired.

Applicative and Time

Look next at the Applicative instance for pairs:

instance Monoid a => Applicative ((,) a) where
  pure x = (mempty, x)
  (u, f) <*> (v, x) = (u `mappend` v, f x)

So Time t must be a monoid, with mempty being the earliest time and mappend being max. We’ll define Time with the help of the Max monoid:

newtype Max a = Max { getMax :: a }
  deriving (Eq, Ord, Read, Show, Bounded)

instance (Ord a, Bounded a) => Monoid (Max a) where
  mempty = Max minBound
  Max a `mappend` Max b = Max (a `max` b)

We could require that the underlying time parameter type t be Bounded, but I want to have as few restrictions as possible. For instance, Integer, Float, and Double are not Bounded, and neither are the types in the Time library. Fortunately, it’s easy to add bounds to any type, preserving the existing ordering.

data AddBounds a = MinBound | NoBound a | MaxBound
  deriving (Eq, Ord, Read, Show)

instance Bounded (AddBounds a) where
  minBound = MinBound
  maxBound = MaxBound

With these two reusable building blocks, our Time definition falls right out:

type Time t = Max (AddBounds t)

Monad

For our Monad instance, we just need an instance for pairs equivalent to the Monad Writer instance.

instance Monoid o => Monad ((,) o) where
  return = pure
  (o,a) >>= f = (o `mappend` o', a') where (o',a') = f a

Consequently (using join m = m >>= id), join ((o, (o',a))) == (o `mappend` o', a). Again, the standard instance implies exactly the desired meaning for futures. Future (t,a) >>= f is available exactly at the later of t and the availability of f a. We might have guessed instead that the time is simply the time of f a, e.g., assuming it to always be at least t. However, f a could result from pure and so have time minBound.

Monoid

The last piece of Future functionality is the Monoid instance, and I don’t know how to get that instance to define itself. I want mappend to yield the earlier of two futures, choosing the first argument when simultaneous. The never-occuring mempty has a time beyond all t values.

instance Ord t => Monoid (Future t a) where
  mempty  = Future (maxBound, error "it'll never happen, buddy")
  fut@(Future (t,_)) `mappend` fut'@(Future (t',_)) =
    if t <= t' then fut else fut'

Coming next

Tune in for the next post, which describes the current implementation of future values in Reactive. The implementation uses multi-threading and is not quite faithful to the semantics given here. I’m looking for a faithful implementation.

A following post will then describe the use of future values in an elegant new implementation of functional reactive programming.