reactive-banana: two FRP implementations in one Haskell library

One library, two implementations, and the split is the design

Reactive-banana is a library for Functional Reactive Programming, written in Haskell, and its most distinctive feature is that the library contains two FRP implementations. The first is Reactive.Banana.Model, described as a model implementation for testing and understanding the semantics, and the README encourages you to look at the source code. The second is Reactive.Banana.Prim, described as the efficient push-driven implementation used for production code, and the README remarks that it contains hard to understand trade secrets. That pairing is the whole argument of the library, and it is a design you can find elsewhere in the Haskell world. The slow version is not a toy or a leftover, it is the specification, written in a way that a reader can check against the behaviour of the fast one, so the question of what the library actually does has an answer that is a page of Haskell rather than a set of invariants. The public API is shared, so the choice between them is a matter of which module you import, and the semantics you depend on are the semantics of the model. The project is BSD3 licensed, with the licence files in the corresponding subdirectories, and the mascot is separately licensed under Creative Commons Attribution 4.0.

Where the code lives, and the build is two steps

The technical overview explains the source layout, and there are two directories. reactive-banana is the core library, and reactive-banana-wx holds bindings to the wxHaskell GUI library and includes many examples. The top level of the repository adds the pieces a Haskell project needs, with a cabal.project, a CONTRIBUTORS file, an ExampleIdeas.md, the README and the mascot image. Building the core library from the source repository is a single line, which changes into the directory and installs with cabal, then leaves it.

    cd reactive-banana && cabal install && cd ..

The GUI examples are a separate matter, because the README says you have to install one of the additional packages to try them, and the prerequisite is wxHaskell.

    cabal install wx

There is a warning attached, that you need a development version of the wxWidgets libraries installed before building wx, and that if you hit ExitFailure 1 exceptions you should follow the wxHaskell Quick Start instructions. Building the wx examples then takes its own sequence, configuring with the buildExamples flag and building.

    cd reactive-banana-wx
    cabal configure -fbuildExamples && cabal build
    cd ..

The two-step structure is worth noting for anyone packaging this. The library is a normal cabal package that installs on its own, and the examples are a separate package with a heavy native dependency, so a project that only wants the library never has to touch wxWidgets.

The documentation lives on the Haskell wiki

The README is short and points outward for everything a user actually needs, with the project homepage at the Haskell wiki for documentation, examples and the rest. The wiki page is the canonical reference for this library, and that placement is itself informative, since it puts the material next to the other FRP discussions in the Haskell community rather than in a repository that would be versioned with the code. The README itself covers what the library is, how to build it, how the source is structured and how to licence it, and the section on installation is the longest part of it, which tells you the library is easy to obtain and the friction is all in the GUI examples. The project is linked from the wiki's functional reactive programming page as a reference implementation, and the repository topics list it as a reactive-banana library, with the frp topic alongside. The contribution record is also substantial. The README thanks everyone who contributed, provided feedback or simply wrote an application using the library, and names Alexander Berntsen, Oliver Charles, Samuel Gélineau, Vladimir Lopatin, Atze van der Ploeg and Mitchell Rosen among them, with special thanks to Oliver Charles and Mitchell Rosen for co-maintaining the project.

The state of the release, and what that means for a new user

The release history is short and dated. The most recent tags are v1.3.1.0 from 2022-08-13 and v1.3.0.0 from 2022-03-28, and the last push to the repository was on 2026-07-19 with the repository not archived. So the code is still being touched while the last published version on Hackage is several years old, which is a pattern you see in libraries that are stable enough to stop releasing and are maintained opportunistically. For a library of this kind that is not alarming in itself, since the API of an FRP core changes rarely, but it does mean a new project will probably not choose it. The Haskell community moved on to other FRP libraries, and the ones that followed generally carry a wider feature set, better performance and an ecosystem around them, so the question for an evaluator is what reactive-banana still does better. The answer is the model implementation, and the reason is the one the README states, that it is for testing and understanding the semantics and you are encouraged to read the source. For a project that wants to understand what a push-driven FRP core actually does before trusting it, a readable model is worth more than a newer fast one. The licence is permissive, a BSD3, so nothing stands in the way of reading it, forking it or vendoring it into something closed.

Where reactive-banana is the wrong choice

The first limit is the age, and it is the one that decides most cases. A library whose last release was in 2022 predates several generations of Haskell tooling, and depending on your compiler and package set you may find yourself working around build issues rather than learning FRP. The second is the scope. This is an FRP core with event sources and sinks and a network of behaviours, and it is not a framework, so anything you need beyond the core, additional event sources, a scheduler, integration with a particular GUI toolkit, you are assembling yourself. The third is the GUI story, since the bundled examples are wxHaskell based and that binding is a heavy native dependency with a documented build failure mode, and the alternatives the project itself references, such as Threepenny-gui, live outside this repository. The fourth is that the whole value proposition depends on your application being a good fit for FRP, which is not true of every program, and a program that is mostly request and response with a bit of state is often clearer written directly. The fifth is the more philosophical one, that FRP in this style is a commitment: once your application is a network of event sources feeding a graph of behaviours, retrofitting that onto an existing codebase is harder than writing a new program in that style, and the library does not offer a path in gradually.

Editorial conclusion

Adopt reactive-banana if you are writing a Haskell application whose structure is naturally event driven, such as a GUI, and you want the semantics spelled out in a source file you can read before trusting the fast path. Skip it if you are starting a new Haskell project, since the ecosystem has moved on and the last tagged release predates most of it, and skip it if you need the wider FRP feature set of a later library. Verify first which behaviour you need from the two implementations, that the version you take from Hackage still builds with your compiler, and that the GUI examples build separately since they need wxHaskell.

Frequently asked questions

Official sources

1. HeinrichApfelmus/reactive-banana on GitHub
2. Issues
3. Project website
4. README
5. Releases