Haskell Blog

FRP - Release of reactive-banana version 0.5

Sun, 25 Mar 2012 21:11:30 +0200

I have released version 0.5.0.0 of my reactive-banana library on hackage.

For this release, I have introduced many changes to the public API and completely rewritten the internals. However, the core FRP model and semantics are merely extended, not changed, so it should be straightforward to port existing code to the new version.

Howdy, cowboy, it’s advertisment time! If you like the reactive-banana project, you can support me with a small donation: Flattr this!. 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.)

The most profound API change is that the types Event, Behavior and NetworkDescription now carry an phantom type parameter t, as discussed in a previous blog post.

Simultaneous event occurrences have long been a point of trouble. With the rewritten internals, I was now able to add combinators like calm or unionWith that allow you to observe and handle simultaneity. This is particularly useful for dealing with incremental updates. Furthermore, I have removed the general Monoid instance for Event to discourage the accidental introduction of simultaneous occurrences. Taking it even further, I have added an experimental module Reactive.Banana.Experimental.Calm that exports a variant semantics where simultaneous occurrences are simply forbidden.

Another noteworthy change is that the Behavior type now partially exposes a notion of “changes”, similar to the old Discrete type, which I have removed again. Suggested by Elliott Hird, this change greatly simplifies your reactive-banana experience as it restores the prominence of the Behavior type. While Behavior is still to be thought of as continuously varying value, the glue code that communicates with GUI frameworks can now observe changes, but only inside the NetworkDescription monad sin-bin. I think that this is a good compromise between elegant semantics and efficient implementation.

Many thanks to all users for suggesting and discussing changes with me, especially Elliott Hird, Gregory Crosswhite and Henning Thielemann.

Some HTML formatting is allowed in comments.
blog comments powered by Disqus