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”).

For quite a while, I’ve been using a handy operation for filtering functional events:

justE :: Event (Maybe a) -> Event a

The idea of justE is to drop the Nothing-valued occurrences and strip off the Just constructors from the remaining occurrences. Recently I finally noticed the similarity with a standard function (in Data.Maybe):

catMaybes :: [Maybe a] -> [a]

I asked on #haskell about a common generalization, and oerjan offered the following:

joinMaybes :: MonadPlus m => m (Maybe a) -> m a
joinMaybes = (>>= maybe mzero return)

I like this name and definition very much, including the use of mzero and return for empty and singleton monadic values, respectively. I particularly like how it works out for lists and events. Each element is passed into maybe mzero return, so that a Nothing becomes empty (mzero), while a Just x becomes a singleton (return x).

I also like how joinMaybes specializes easily into traditional, predicate-based filtering, generalizing the standard filter function on lists:

filterMP :: MonadPlus m => (a -> Bool) -> m a -> m a
filterMP p m = joinMaybes (liftM f m)
 where
   f a | p a       = Just a
       | otherwise = Nothing

So it’s easy to define filterMP in terms of joinMaybes (and hence filter in terms of catMaybes). What about the reverse? Here’s one go at it:

filterMP' :: MonadPlus m => (a -> Bool) -> m a -> m a
filterMP' p = (>>= f)
 where
   f a | p a       = return a
       | otherwise = mzero

joinMaybes' :: MonadPlus m => m (Maybe a) -> m a
joinMaybes' = liftM fromJust . filterMP' isJust

Comparable simplicity, but I don’t like the isJust and fromJust. Not only is there some redundant checking, but the fromJust function is partial, and so this definition is not so obviously total to an automated checker like Catch.

Edit 2008-02-08: added a “Continue reading …” token, to keep my blog’s front page uncluttered.