Some time ago I tried to create big programs with user interfaces in Haskell and found that none of the FRP frameworks worked as expected. Some were incomplete, others didn’t compile, and efficiency was an issue in those that did work.
I ended up writing a very simple event-driven framework to write desktop applications in Haskell using GTK. The idea is as follows:
– Both the user interface and the model (MVC architecture) of your app are viewed as a collection of reactive fields.
– Reactive fields are RW/RO/WO typed values with a setter, a getter and an event notifier.
– You can use the operators =:=, =:> and <:= to establish equivalences between fields.
– You can lift functions to the level of reactive fields.
– If you want to, you can write your condition using good-old gtk2hs IO-monad Haskell. Or combine one syntax and the other.
– The model is enclosed in a thread-safe section using STM. This is done for you automatically.
– For fields with simple getters/setters, you can derive the implementation on the field based on the definition in the model. The default implementation uses == (Eq class) to avoid loops (model updates view, view updates model, model updates view, etc.)
– There are default definitions for the most important fields of some GTK widgets. In general, it’s dead simple to create your own.
– You can make any attribute of a GTK widget reactive, not just the main attribute.
– There is no sense of time. Equivalences must always hold.
– The framework gives you undo/redo capabilities automatically. It records all changes to the model and the events that each change triggered, so that, when you undo/redo, only the minimal part of the UI is updated.
– The framework generates some classes automatically, but these are not overwritten if you have modified them.
– It works a-la-ruby-on-rails/yesod: certain files are expected to be in certain places. If you move them around, you’ll have to modify the generated files to point to the right place.
– It is extensible: gtk is only used at the highest level. Other libraries could be used instead.
– Keera Hails is not FRP. While some concepts and problems may overlap, it is not based on the ideas of FRP. In particular: there’s no time, there’s no sense of continuously-changing values.
Our repo has several applications created using this framework. You can see how the framework is used. Some applications call the program ‘hails’ to generate some code automatically.
The framework is composed of several libraries, but the main one is this:
This sample app uses Keera Hails