FRP - Release of reactive-banana version 0.7
It’s time to celebrate! I have just released version 0.7.0.0 of my reactive-banana library on hackage!
This version is a big step forward as it features dynamic event switching, which means that you can now make an event which contains other events and do useful things with it. The event will have a type like Event (Event A) and you can, for instance, dynamically switch between the inner events by using the new switchE combinator.
The BarTab.hs example demonstrates the new possibilities. It shows how to create new widgets and behaviors in reaction to event occurrences. When you click the “Add” button, a new edit widget will be added and it’s Behavior will contribute to the total sum.
While dynamic event switching is great news, I also have to point out that version 0.7.0.0 of reactive-banana is a highly experimental release (for my standard of “highly experimental”). Dynamic event switching is not easy to get right, and while I have managed to avoid the dreaded time leaks, there are still major issues with garbage collection. They can be solved, but for now, I wanted to get my preliminary code out there, so that you can experiment with the library and send me your valuable feedback.
API elegance
Aside from efficiency, the other issue with dynamic event switching is that the API is rather complex. This is necessary if we want to void time leaks, but the whole thing does become a little less elegant than the original vision for FRP would have it.
(I will explain the new API in a subsequent post.)
Fortunately, there are several distinct ways to incorporate dynamic event switching into the API.
My “banana-nemesis”, the sodium library, uses an approach first described by Gergely Patai, which forces all accumulating combinators like stepper or accumE into a monad. This is conceptually simple, but I think the notational burden is quite high.
I have taken another approach, which keeps the first-order interface intact, but introduces some additional complexity when you want to use dynamic event switching. My approach was inspired by Wolfgang Jeltsch’s use of rank-2-polymorphism, but goes beyond it and can now express significantly more programs.
I don’t know which of these two API approaches is more convenient to use. Since dynamic event switching is needed rather seldomly, I found it more important to present beginners with a simple first-order API, and to make the higher-order stuff entirely optional. Besides, I thought it would be a good idea to explore a different part of the design space than the sodium library already does. Give it a try and tell us how it works for you!
Changelog
Aside from the new module Reactive.Banana.Switch, the main change compared to the previous 0.6 release is that the NetworkDescription monad is now called Moment and it has a new constraint on the type parameter. You have to exchange the old type
NetworkDescription t afor the new type
Frameworks t => Moment t aeverwhere.
Moreover, the current version can no longer be compiled with the JavaScript backend of the Utrecht Haskell Compiler. There is no fundamental obstacle to that, as I don’t use any significant GHC-specific extensions; I just haven’t put the time into making this compatible yet. But do note that future versions of reactive-banana will need GHC extensions like weak pointers, so that the problems with garbage collection can be resolved.
Advertisment
Howdy, cowboy, it’s advertisment time! If you like the reactive-banana project, you can support me with a small donation: 
. Furthermore, at the end of every month, all ardent supporters will receive ¢2 worth of status information and fruity puns! (This magnificent offer can be respectfully declined in your Flattr preferences.)