Question

I’m working on a program using reactive-banana, and I’m wondering how to structure my types with the basic FRP building blocks.

For instance, here’s a simplified example from my real program: say my system is composed primarily of widgets — in my program, pieces of text that vary over time.

I could have

newtype Widget = Widget { widgetText :: Behavior String }

but I could also have

newtype Widget = Widget { widgetText :: String }

and use Behavior Widget when I want to talk about time-varying behaviour. This seems to make things “simpler”, and means I can use Behavior operations more directly, rather than having to unpack and repack Widgets to do it.

On the other hand, the former seems to avoid duplication in the code that actually defines widgets, since almost all of the widgets vary over time, and I find myself defining even the few that don’t with Behavior, since it lets me combine them with the others in a more consistent manner.

As another example, with both representations, it makes sense to have a Monoid instance (and I want to have one in my program), but the implementation for the latter seems more natural (since it’s just a trivial lifting of the list monoid to the newtype).

(My actual program uses Discrete rather than Behavior, but I don’t think that’s relevant.)

Similarly, should I use Behavior (Coord,Coord) or (Behavior Coord, Behavior Coord) to represent a 2D point? In this case, the former seems like the obvious choice; but when it’s a five-element record representing something like an entity in a game, the choice seems less clear.

In essence, all these problems reduce down to:

When using FRP, at what layer should I apply the Behavior type?

(The same question applies to Event too, although to a lesser degree.)

Answer 1

I agree with dflemstr’s advice to

1. Isolate the “thing that changes” as much as possible.
2. Group “things that change simultaneously” into one Behavior/Event.

and would like to offer additional reasons for these rules of thumb.

The question boils down to the following: you want to represent a pair (tuple) of values that change in time and the question is whether to use

a. (Behavior x, Behavior y) – a pair of behaviors

b. Behavior (x,y) – a behavior of pairs

Reasons for preferring one over the other are

• a over b.

  In a push-driven implementation, the change of a behavior will trigger a recalculation of all behaviors that depend on it.

  Now, consider a behaviors whose value depends only on the first component x of the pair. In variant a, a change of the second component y will not recompute the behavior. But in variant b, the behavior will be recalculated, even while its value does not depend on the second component at all. In other words, it’s a question of fine-grained vs coarse-grained dependencies.

  This is an argument for advice 1. Of course, this is not of much importance when both behaviors tend to change simultaneously, which yields advice 2.

  Of course, the library should offer a way to offer fine-grained dependencies even for variant b. As of reactive-banana version 0.4.3, this is not possible, but don’t worry about that for now, my push-driven implementation is going to mature in future versions.

• b over a.

  Seeing that reactive-banana version 0.4.3 does not offer dynamic event switching yet, there are certain programs that you can only write if you put all components in a single behavior. The canoncial example would be a program that features variable number of counters, i.e. an extension of the TwoCounter.hs example. You have to represent it as a time-changing list of values

  counters :: Behavior [Int]
  

  because there is no way to keep track of a dynamic collection of behaviors yet. That said, the next version of reactive-banana will include dynamic event switching.

  Also, you can always convert from variant a to variant b without any trouble

  uncurry (liftA2 (,)) :: (Behavior a, Behavior b) -> Behavior (a,b)