Which FRP package to choose? [closed]

Question

I'm just starting to look into the world of Functional Reactive Programming in Haskell, and I would like to experiment with GUI programming (with gtk, because of substantial binding) in a reactional setting.

Now, I've been looking a bit at Grapefruit, Reactive-Banana and Buster, and I would like any testament to the joy/horror of using any one or other package.

All I have is these preliminary oppinions:

• I don't mind doing some of the binding of the FRP package to gtk myself, as I have an ambivalet feeling about the abstracted backend idea (that Grapefruit has)..

• While I find type theory interesting, I also value simple encodings for actual programs, which seems to put grapfruit-records a bit off..

That is, unless of course some of you persuades me to think otherwise :-)

Terni

"graprefuit" and "reactive-banana"? Is there some special affinity between frp and fruit? – Dendro

@benw: I believe the "banana" part is a reference to a paper with one of the most amusing titles I know: Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire. – Life

@hammar: Haha, nice! Actually, I chose the name "banana" for different reasons, but I like the one mention. – Draconic

possible duplicate of What's the status of current Functional Reactive Programming implementations? – Morse

@HeinrichApfelmus Intriguing - what reasons? – Uintathere

@Uintathere It's actually a reference to the "peanut butter jelly" video. Animations are a good example for explaining the essence of FRP, and I thought that a dancing banana is the best example animation for this purpose. – Draconic

Answer 1

If you just want to use regular FRP, and stay close to the GUI framework rather than using a "pre-made" abstraction over it, reactive-banana is the most viable option, in my opinion. It's explicitly geared around binding to existing frameworks, is designed for "real-world" use (not doing anything too experimental, semantically, that could cause problems), and so on.

You can take a look at reactive-banana-wx to see how to bind an event-based framework to reactive-banana. It's very simple; I wrote a quick binding to Gtk2Hs once (lost the code now, unfortunately), and the file didn't go over 50 lines. It was almost a direct transliteration of the reactive-banana-wx code.

I would recommend against using Buster, for the simple reason that it hasn't been updated since 2009, and doesn't build on GHC 7.

Other "production-oriented" FRP frameworks are sodium (similar to reactive-banana, but it has dynamic event switching (which is coming to reactive-banana soon, but isn't in yet) and a concept of "partitions" for concurrency; however, it's just come out and hasn't seen adoption yet) and netwire (arrowised FRP, quite a different creature to reactive-banana and sodium).

Expellee

update: switching is in reactive banana as of version 0.7.0.0 – Uintathere

(However, Heinrich Apfelmus is still (2013.06.20) working on the garbage collection of dynamic event switching, so use with caution at the moment.) – Uintathere

Answer 2

I've been experimenting with FRP myself and so far the only one that's worked for me is Reactive-Banana. I never looked into Grapefruit or most of the others because they were out of date and didn't seem like they were likely to be updated or supported at all. I did briefly look at netwire, but frankly all the arrow theory in it put me off and I had a lot of trouble figuring out how to do even simple things.

In contrast I've managed to get a pretty good set of bindings to SDL written in Reactive-Banana with only a few hiccups along the way. Another thing in favor of Reactive-Banana is that Heinreich is very active in the community and will often provide helpful answers when you run into problems. Just look through the various reactive-banana questions on here and you'll see he's responded to quite a few of them and he's usually very active in FRP discussions in the Haskell mailing lists.

Genteel

Opinionated answers are sometimes exactly what you need! Thanks! – Shirleneshirley