Functionally Reactive Programming: What in the World?

Dennis J. McWherter, Jr. bio photo By Dennis J. McWherter, Jr. Comment

Maybe you have heard the term by now or maybe you haven€™t: Functional Reactive Programming (or FRP for short). While learning about this topic, I found many resources… each of which proved to be hardly useful to my understanding of this topic. For instance, consider what wikipedia has to say about it (though I admit this was a good pointer). While I don€™t trust wikipedia as a definitive source, it usually has a decent amount of information to give you a broad picture about any particular topic. In this case, it (as well as many other sources) provides very little value into actually understanding FRP. I aim to provide a brief overview of the topic as well as pointers to the most helpful resources I could find about it.

I know what you€™re thinking: if it€™s so difficult to explain, then why do we care about it? I mean, no one could be using this idea then, right? Well, not exactly. While my references will primarily use Haskell to explain these concepts, they also apply to Javascript and any other language with the necessary functional components.

Let us begin by first describing the problem we€™re trying to solve: we have an application running and we want it to respond (or react) to asynchronous (or external) events. Functional Reactive Programming is a functional approach to dealing with asynchronous data streams. I€™m sure you understood most of those words, but what do I mean by €œasynchronous data streams€? Well, I mean exactly that, but consider the following example. You are creating a piece of software that runs and allows a user to interact with it. When the user sends an event (i.e. a mouse click or hits enter on the keyboard) to your application, this is asynchronous assuming you are performing some other work while the user performs an action (read: prompting and waiting on the user for input doesn€™t count). In summary, you cannot know when the user will provide you with an event, but you want to respond quickly when he or she does. When data can come in at anytime, that is the asynchronous data stream. As you may have guessed, this technique is commonly employed for building front-ends (but we€™ll get to that).

If you€™re interested in the inception of FRP, see the original paper which (more accurately) describes this in the context of models as functions of time.

As you can see in the wikipedia article, there are typically two forms of FRP:

  1. Continuous FRP. The application is continuously refreshed at some defined sample rate (since computers are actually discreet machines). This means everything is refreshed in your element.
  2. Discrete FRP. This approach is €œevent-driven.€ That is, when a change occurs only the affected components of your application are updated. This tends to be the more practical and useful approach unless your application has need for everything to be constantly updating. These events are time-ordered.

This brings up to a pressing question then: what is functional reactive program used for? If you search for this anywhere, you€™ll get a similar list: animations, computer vision, user interfaces, and simulation. Unfortunately, most of these use-cases require special hardware that most people don€™t have. As a result, most of the examples show one of the two: GUI creation or animation. I will move on and link to some example, but first: if you don€™t feel like you understand how this concept is useful yet then check out the information presented here (read: there€™s pretty pictures).

Overall, the most useful bit of examples I found were simply the reactive-banana examples. Reactive-banana is a Haskell framework for building out a reactive program. It uses the concepts of €œEvents€ and €œBehaviors€ to model streaming. Rather than rewrite this article, I€™ll let you go read it. The examples provided by these two resources are useful since you see how reactive-banana gives you all of the flexibility you€™re looking for while using FRP.

Similarly, most (all?) of the reactive-banana-examples are written to interface with wx (GUI software). For those of you who don€™t already know, wxWidgets is a light-weight, mature, cross-platform GUI framework which has Haskell bindings (known as wx in hackage). As a result, wx already has an event system in place which mirrors the original imperative code. The reactive-banana-examples demonstrate how to use the reactive-banana FRP framework in conjunction with the wx GUI library. I find that this provides better intuition and example about the overall power of FRP and its applicability (though I do admit, their Reactive.Banana.WX helpers would be nice to have in hackage). 

Now that you are aware of the concept of Functional Reactive Programming and have some pointers, go take a look and see what you can do with it. I€™m sure it will make your code cleaner in the long run.

comments powered by Disqus