Where to apply Behavior (and other types) in FRP

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

The rules I use when developing FRP applications, are:

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

The reason for (1) is that it becomes easier to create and compose abstract operations if the data types that you use are as primitive as possible.

The reason for this is that instances such as Monoid can be reused for raw types, as you described.

Note that you can use Lenses to easily modify the "contents" of a datatype as if they were raw values, so that extra "wrapping/unwrapping" isn't a problem, mostly. (See this recent tutorial for an introduction to this particular Lens implementation; there are others)

The reason for (2) is that it just removes unnecessary overhead. If two things change simultaneously, they "have the same behavior", so they should be modeled as such.

Ergo/tl;dr: You should use newtype Widget = Widget { widgetText :: Behavior String } because of (1), and you should use Behavior (Coord, Coord) because of (2) (since both coordinates usually change simultaneously).

Answer 2

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)