Asynchronous Functional Reactive Programming for GUIs

---

The Elm described in this paper[1] is somewhat different from the Elm that one would learn today. The "functional reactive" bit has been replaced with a system of Subscriptions that allow concurrent UIs without using Signals[2]. Still, when reading this paper its clear that the authors are already on this path. Classical FRP is most easily conceived in terms of animation[3] [4]. The fundamental type of an FRP system is the Signal, a value that varys unpredictably over time. Signals can be composed of other signals and computation described by pure functions. Changes in Signals propogate synchronously through the graph of dependenet signals. Some of these Signals are consumed by functions which render visual elements.

Conceptually, Signals are values that vary over time, so the function must be able to produce an image for any time value. Continuous transformations of elements are produced by rapid sampling. In practice, most signals are not received whole from the world, they are the product of computations on other Signals. Keeping all of the signals up to date requires rapid reprocessing.

Elm diverges from this thinking in that Signals don't simply vary with time, they vary with the occurence of specific events. Speaking broadly, classical FRP systems don't model the causes of changes in signals, they simply calculate the value of the signals frequently enough that they appear to respond instantly to changes. In Elm, the causes to changes in signals are known which allows two imporant opportunities. First, Elm programs don't have to do as much work because calculations only occur when events cause signals to change. Second, given the ability to model dependencies in causes to changes in signals, programmers can specify that some signal processing can happen asynchronously.

This is a useful example of a situation where the conceptual purity of Signals may not pay for the cost of abstraction. Many optimizations to FRP take advantage of the same techniques that Elm uses. Asynchrous event handling is at the heart of most GUI systems for a reason. The context of Javascript developement in 2012, the height of asynch everthing madness, provided fertile ground for this extension of FRP. That's not to say that thinking about Signals was fruitless. The concept of a Signal Graph is important because creating an ordering of Signals provided a much safer way of reasoning about concurrency than simply responding to events as they arrived. I would argue that this is an inchoate expression of the Subscription concept that would replace Signals.

Currently, Elm moves even farther from classic FRP. The system of discrete signals has been completely replaced. This is not an isolated case. React, Om, Redux, Halogen, Reagent are exploring this area as well. I'm not sure it has a name now, but it is certainly concurrent and functional. The common thread is that rendering can be optimized by systematically managing responses to changes. A critical part of this has come from the notion that a discrete set of elements can be rendered from a global application state. HTML provides a model for these elements and its no coincedence that React began life rendering HTML. Elm's author also started in the browser context, but inspired by the tradition of FRP he avoided HTML elements as much as possible and started fresh with raster graphics in a canvas element. This proved to be an unnessary (and maybe counterproductive[5]) effort and Elm now has HTML element rendering at its core.

As an aside, I brought these ideas of seperation of state, change, and rendering up in the Visual Analytics Reading Group at SIAT and one of my commititee members haruphed and said something like, "I did that in VR 30 years ago"[6].

---

© Ethan Soutar-Rau. Site proudly generated by Hakyll