What's the status of current Functional Reactive Programming implementations?

Question

I'm trying to visualize some simple automatic physical systems (such things as pendulum, robot arms,etc.) in Haskell. Often those systems can be described by equations like

df/dt = c*f(t) + u(t)

where u(t) represents some kind of 'intelligent control'. Those systems look to fit very nicely in the Functional Reactive Programming paradigm.

So I grabbed the book "The Haskell School of Expression" by Paul Hudak, and found that the domain specific language "FAL" (for Functional Animation Language) presented there actually works quite pleasently for my simple toy systems (although some functions, notably integrate, seemed to be a bit too lazy for an efficient use, but easily fixable).

My question is, what's the more mature, up-to-date, well-maintained, performance-tuned alternative for more advanced, or even practical applications today?

This wiki page lists several options for Haskell, but I'm not clear about the following respects:

1. The status of "reactive", the project from Conal Eliott who is (as I understand it) one of the inventers of this programming paradigm, looks a bit stale. I love his code, but maybe I should try other more up-to-date alternatives? What's the primary difference between them, in terms of syntax/performance/runtime-stability?

2. To quote from a survey in 2011, Section 6, "... FRP implementations are still not efficient enough or predictable enough in performance to be used effectively in domains which require latency guarantees ...". Alghough the survey suggests some interesting possible optimizations, given the fact that FRP is there for more than 15 years, I get the impression that this performance problem might be something very or even inherently difficult to solve at least within a few years. Is this true?

3. The same author of the survey talks about "time leaks" in his blog. Is the problem unique to FRP, or something we are generally having when programming in a pure, non-strict language? Have you ever found it just too difficult to stabilize an FRP-based system over time, if not performant enough?

4. Is this still a research level project? Are the people like plant engineers, robotics engineers, financial engineers, etc. actually using them (in whaterver language that suits their needs)?

Although I personally prefer a Haskell implementation, I'm open to other suggestions. For example, it would be particularly fun to have an Erlang implementation --- it would then be very easy to have an intelligent, adaptive, self-learning server process!

Armanda

Answer 1

Right now there are mainly two practical Haskell libraries out there for functional reactive programming. Both are maintained by single persons, but are receiving code contributions from other Haskell programmers as well:

• Netwire focusses on efficiency, flexibility and predictability. It has its own event paradigm and can be used in areas where traditional FRP does not work, including network services and complex simulations. Style: applicative and/or arrowized. Initial author and maintainer: Ertugrul Söylemez (this is me).

• reactive-banana builds on the traditional FRP paradigm. While it is practical to use it also serves as ground for classic FRP research. Its main focus is on user interfaces and there is a ready-made interface to wx. Style: applicative. Initial author and maintainer: Heinrich Apfelmus.

You should try both of them, but depending on your application you will likely find one or the other to be a better fit.

For games, networking, robot control and simulations you will find Netwire to be useful. It comes with ready-made wires for those applications, including various useful differentials, integrals and lots of functionality for transparent event handling. For a tutorial visit the documentation of the Control.Wire module on the page I linked.

For graphical user interfaces currently your best choice is reactive-banana. It already has a wx interface (as a separate library reactive-banana-wx) and Heinrich blogs a lot about FRP in this context including code samples.

To answer your other questions: FRP isn't suitable in scenarios where you need real-time predictability. This is largely due to Haskell, but unfortunately FRP is difficult to realize in lower level languages. As soon as Haskell itself becomes real-time-ready, FRP will get there, too. Conceptually Netwire is ready for real-time applications.

Time leaks aren't really a problem anymore, because they are largely related to the monadic framework. Practical FRP implementations simply don't offer a monadic interface. Yampa has started this and Netwire and reactive-banana both build on that.

I know of no commercial or otherwise large scale projects using FRP right now. The libraries are ready, but I think the people aren't – yet.

Necrose

Great answer, thanks.. it will be a fun excercise to implement some reinforcement learning algorithms on top of your library. – Armanda

Notably, a recent indie game written in Haskell (Nikki and the Robots) made the decision not to use FRP. – Gianina

Answer 2

Although there are some good answers already, I'm going to attempt to answer your specific questions.

1. reactive is not usable for serious projects, due to time leak problems. (see #3). The current library with the most similar design is reactive-banana, which was developed with reactive as an inspiration, and in discussion with Conal Elliott.

2. Although Haskell itself is inappropriate for hard real-time applications, it is possible to use Haskell for soft realtime applications in some cases. I'm not familiar with current research, but I don't believe this is an insurmountable problem. I suspect that either systems like Yampa, or code generation systems like Atom, are possibly the best approach to solving this.

3. A "time leak" is a problem specific to switchable FRP. The leak occurs when a system is unable to free old objects because it may need them if a switch were to occur at some point in the future. In addition to a memory leak (which can be quite severe), another consequence is that, when the switch occurs, the system must pause while the chain of old objects is traversed to generate current state.

Non-switchable frp libraries such as Yampa and older versions of reactive-banana don't suffer from time leaks. Switchable frp libraries generally employ one of two schemes: either they have a special "creation monad" in which FRP values are created, or they use an "aging" type parameter to limit the contexts in which switches can occur. elerea (and possibly netwire?) use the former, whereas recent reactive-banana and grapefruit use the latter.

By "switchable frp", I mean one which implements Conal's function switcher :: Behavior a -> Event (Behavior a) -> Behavior a, or identical semantics. This means that the shape of the network can dynamically switch as it's run.

This doesn't really contradict @ertes's statement about monadic interfaces: it turns out that providing a Monad instance for an Event makes time leaks possible, and with either of the above approaches it's no longer possible to define the equivalent Monad instances.

Finally, although there's still a lot of work remaining to be done with FRP, I think some of the newer platforms (reactive-banana, elerea, netwire) are stable and mature enough that you can build reliable code from them. But you may need to spend a lot of time learning the ins and outs in order to understand how to get good performance.

Forwhy

Concerning the arrow-based libraries (Yampa, netwire), they are switchable, too. The reason is that arrows have aging built-in, you can't actually get rid of it. (Being stream transformers, arrows are agnostic about the starting time of their input stream.) – Bedesman

Don't forget the reactive-banana's banana-nemesis: sodium. – Dispassionate

@HeinrichApfelmus: that's an interesting point. I don't generally think of arrow-based libraries as switchable in the same way that elerea/grapefruit/current-reactive-banana are. I think their switching is a lot closer to what was required in previous versions of reactive-banana. This is just a gut feeling though, I haven't given it enough thought to even describe what I mean. – Forwhy

@DanBurton thanks, I was trying unsuccessfully to remember that name. I agree that sodium should be considered a modern FRP library, although it's not as popular as reactive-banana. – Forwhy

Although the discussion going on is a bit difficult to follow, it seems to indicate that a soft-realtime system is indeed possible, provided the GC time can in some way be bounded. Anyway thanks for your great answer. – Armanda

Answer 3

I'm going to list a couple of items in the Mono and .Net space and one from the Haskell space that I found not too long ago. I'll start with Haskell.

Elm - link

Its description as per its site:

Elm aims to make front-end web development more pleasant. It introduces a new approach to GUI programming that corrects the systemic problems of HTML, CSS, and JavaScript. Elm allows you to quickly and easily work with visual layout, use the canvas, manage complicated user input, and escape from callback hell.

It has its own variant of FRP. From playing with its examples it seems pretty mature.

Reactive Extensions - link

Description from its front page:

The Reactive Extensions (Rx) is a library for composing asynchronous and event-based programs using observable sequences and LINQ-style query operators. Using Rx, developers represent asynchronous data streams with Observables, query asynchronous data streams using LINQ operators, and parameterize the concurrency in the asynchronous data streams using Schedulers. Simply put, Rx = Observables + LINQ + Schedulers.

Reactive Extensions comes from MSFT and implements many excellent operators that simplify handling events. It was open sourced just a couple of days ago. It's very mature and used in production; in my opinion it would have been a nicer API for the Windows 8 APIs than the TPL-library provides; because observables can be both hot and cold and retried/merged etc, while tasks always represent hot or done computations that are either running, faulted or completed.

I've written server-side code using Rx for asynchronocity, but I must admit that writing functionally in C# can be a bit annoying. F# has a couple of wrappers, but it's been hard to track the API development, because the group is relatively closed and isn't promoted by MSFT like other projects are.

Its open sourcing came with the open sourcing of its IL-to-JS compiler, so it could probably work well with JavaScript or Elm.

You could probably bind F#/C#/JS/Haskell together very nicely using a message broker, like RabbitMQ and SocksJS.

Bling UI Toolkit - link

Description from its front page:

Bling is a C#-based library for easily programming images, animations, interactions, and visualizations on Microsoft's WPF/.NET. Bling is oriented towards design technologists, i.e., designers who sometimes program, to aid in the rapid prototyping of rich UI design ideas. Students, artists, researchers, and hobbyists will also find Bling useful as a tool for quickly expressing ideas or visualizations. Bling's APIs and constructs are optimized for the fast programming of throw away code as opposed to the careful programming of production code.

Complimentary LtU-article.

I've tested this, but not worked with it for a client project. It looks awesome, has nice C# operator overloading that form the bindings between values. It uses dependency properties in WPF/SL/(WinRT) as event sources. Its 3D animations work well on reasonable hardware. I would use this if I end up on a project in need for visualizations; probably porting it to Windows 8.

ReactiveUI - link

Paul Betts, previously at MSFT, now at Github, wrote that framework. I've worked with it pretty extensively and like the model. It's more decoupled than Blink (by its nature from using Rx and its abstractions) - making it easier to unit test code using it. The github git client for Windows is written in this.

Comments

The reactive model is performant enough for most performance-demanding applications. If you are thinking of hard real-time, I'd wager that most GC-languages have problems. Rx, ReactiveUI create some amount of small object that need to be GCed, because that's how subscriptions are created/disposed and intermediate values are progressed in the reactive "monad" of callbacks. In general on .Net I prefer reactive programming over task-based programming because callbacks are static (known at compile time, no allocation) while tasks are dynamically allocated (not known, all calls need an instance, garbage created) - and lambdas compile into compiler-generated classes.

Obviously C# and F# are strictly evaluated, so time-leak isn't a problem here. Same for JS. It can be a problem with replayable or cached observables though.

Stiffnecked

Thanks for the great answer. One of the things I liked for Haskell FRP implementations is that they seem to allow me to cleanly decouple the computations for the control u(t) and the simulations for f(t). Is that the case for F# implementations? – Armanda

I guess you can say that those two functions are temporally decoupled, yes. They are probably not logically decoupled though. ;) – Stiffnecked

As far as I know, Reactive Extensions and the other more polished UI--focused packages (and everything outside of Haskell, in fact) use only evented semanics -- which is to say that they have a notion of events you can switch on, but not a notion of continuous time signals which can interact equationally. For building guis this is fine, I think. However, for building simulations and models, this may be unfortunate. – Vannavannatta

Are you implying that all functional reactive programming lib implementations need to model time continuously rather than discretely? I have found a paper called "Process Algebra with Timing: Real Time and Discrete Time" - is this a good starting point to understand what you are talking about? – Stiffnecked

I'm not saying all need to -- some do, some don't. But those that do are more suited for certain tasks, and those that don't are more suited for others... – Vannavannatta