Learning Functional Reactive Programming

Functional Reactive Programming (FRP) is a programming technique that I think hasn’t filtered down to the level of workaday programmers (like myself) but is well-regarded in the academic community.

Upside is that it could make writing Gtk and web applications much simpler.

Downside is that no one from the academic world has ever managed to explain FRP in a way that makes any sense to mere mortals. There are, as far as I can see, no good tutorials about FRP on the web, and by “good” I mean to exclude any that mention words like “composition”, “point-free”, “point-wise”, “denotational” or any other jargon like that.

Well, this one isn’t too bad … What I really need though are real, concrete, compilable examples.

The inimitable Daniel Bünzli, author of the OCaml FRP framework React wrote his own intro to FRP today, although I’m still not convinced I understand it.

So I’m going to learn it, and if I can, describe it to you in some forthcoming posts.

But what everyone agrees on are the basics: FRP is about putting the imperative programming concept of a “variable” on a sound theoretical basis. Let me explain …

In C you can declare a variable, like:

#define UP 1
#define DOWN 2
int mouse_button_state = UP;

and you can assign to that C variable over the course of your program:

void button_pressed (void)
  mouse_button_state = DOWN;

The problem[1] is that mouse_button_state changes as time passes, but the variable itself doesn’t capture the past, present or future of the variable. Assigning a new value to the variable (a) doesn’t record the time that the variable changed, and (b) obliterates all previous states of the variable. The variable has no memory of what happened before.

[1] I’m using the word “problem” advisedly here. You and I might not think this is a problem at all. But FRP is going to persuade us that this is a problem and by putting variables on a sounder theoretical basis, our programs will be shorter and easier to reason about.

C programs that really deal with mouse events are, of course, full of callbacks. When a mouse button changes state (or more often, when it changes state several times) we want to call back some function that takes an action in response to user input. Callbacks are a huge problem in imperative programs, as you’ll know if you’ve ever done anything non-trivial. Amongst the problems are (1) they run asynchronously, (2) they run in some other part of the program and it’s not obvious what runs when and where, and (3) they often have bad interactions when several callbacks run and they might be called in different orders.

FRP promises to fix this, again by modeling events on a sound theoretical basis.

FRP also promises to save us from reasoning about: complicated multithreaded programs, event-driven programs (like operating systems, libvirt, etc.), writing web applications, and writing GUI applications.

I’m yet to be convinced, but I’m going to learn about FRP and try to write the world’s first usable FRP tutorial.



Filed under Uncategorized

14 responses to “Learning Functional Reactive Programming

  1. Matt

    As someone who has sat in hours of lectures on FRP, even the faculty who espouse it don’t really understand it either. *yawn*

    • rich

      Matt, I don’t know if “yawn” is directed at me and my attempts at a tutorial, or FRP in general. But I’m not convinced by any idea until I try it myself. I haven’t tried FRP, but I’m going to soon, and then I’ll see if it’s worthwhile, and I’ll try to translate that into something ordinary programmers can understand.

  2. choeger

    So what is actually the difference to monadic programming for state changes? (Which is actually the “state of the art” way to handle events in FP)

  3. You might be interested in this post about FRP for AJAX with the froc library:


    Froc is quite similar to React in many ways (both take ideas from the FrTime / Flapjax style of FRP, as opposed to the various Haskell FRP systems). It differs in that it has a monadic interface, has a simpler implementation, and can run in a browser with ocamljs.

  4. Jonathan

    I’ve made a few attempts to crack this nut and have always failed to understand it in any significant way. I’m looking forward to reading the tutorial. Hopefully, it will help.

  5. alpmestan

    I’m already impatient to see your introduction to FRP. I’ve understood the bits of it I’ve read about but I’m still to be “convinced”, to just “get” how it solves everything.

  6. On the frp promises, I would be very careful as I wrote elsewere


    we need more experiments. At least for myself I’d say I don’t have enough experiences with non-toy program to really assert the benefits and problems of frp. I wrote react to make more experiences, but so far I hadn’t the time to make them.

    Other than that, yes, learning by doing is the only way.


  7. Ronan

    I found that after reading this Flapjax tutorial (a framework for FRP in Javascript), I could understand most of Daniel’s documentation :

    (Daniel calls a “signal” what Flapjax calls a “behaviour”.)

    Hope that helps.

  8. david m.

    Hello Richard,

    I’m also looking forward to reading your introduction to FRP.


  9. Pingback: OCaml Users Meeting, Paris, April 2010 « Richard WM Jones

  10. I just stumbled over your blog post while searching for FRP and wanna let you know that I’m currently learning FRP myself and writing some tutorials at http://lambdor.net (using Haskell/Yampa).

    > What is FRP?

    While in contrast to transformational systems (1) where you have functions that do calculation, and in contrast to interactive systems (2) where you occasionally get user input, in reactive systems (3) you constantly get input from the environment (devices, user input, sensors) and want to deal with them in a very abstract way. Coming from a games background these “reactions” are time (abstracted in behaviors or signal functions) and user input (abstracted in events). When the time is updated, the signal functions change and everything else that depend on them (hence: react to it). A reactive language thus allows you to bundle together this “reactive functions” (player movement, animations etc.) in a very concise way.

    > “variable”

    I think you mean that signal functions can be “stateful” (remember their previous state) as their current output (in theory) depends on ALL their previous inputs. A simple example is an integrator, which grows over time but you just call it with (integrate 1) everytime.

  11. jeremysawesome

    Whatever happened to this series? Did you finish? If so, where are the next posts in the series?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.