17

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.)

ehird
  • 39,804
  • 3
  • 173
  • 180

2 Answers2

6

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).

dflemstr
  • 25,186
  • 5
  • 66
  • 102
  • I don't think lenses help here — to use the `Monoid` example, it's that something like `f = liftA2 mappend` becomes `f a b = Widget $ mappend (widgetText a) (widgetText b)`. Admittedly, lifting combinators can ease this pain. However, I'm not sure what you're trying to say by referencing my `Monoid` example — it was meant to be an argument for the `String` form, not the `Behavior String` form. – ehird Dec 21 '11 at 22:34
  • Your rules sound very good, though, and I'll have to think about it some more. Thanks very much for posting this! I'll not accept this answer just yet since I'd like to hear other views and perspectives and since it's quite a subtle question. – ehird Dec 21 '11 at 22:36
  • In your `Widget` example, it only contains `widgetText` which makes raw lifting trivial. If you had had more values in a `Widget`, raw lifting becomes much more complicated than lifting a `Behavior` through a lens and performing operations on it that way. – dflemstr Dec 21 '11 at 22:42
  • Ah, you mean something like `liftL2 :: Lens a b -> (b -> b -> b) -> a -> a -> a`? (Hmm, I suppose you might be able to make that lifting pattern into an applicative functor.) – ehird Dec 21 '11 at 22:47
  • But that has an obvious issue: which argument do you put the resulting value back into? I think using lenses on multiple values like this is a misuse. – ehird Dec 21 '11 at 22:48
  • You can't make `Monoid` instances for multi-field `Widget`s that only care about `widgetText`, of course. When the `Widget` has more members, you would perform different operations on it. I might have been unclear: Isolation of data leads to reuse of instances such as `Monoid`. If that isolation also leads to tedious un/rewrapping, you can use Lenses to make that un/rewrapping less tedious. These are two separate points; I never said that using Lenses with `Monoid`s might be a good idea. – dflemstr Dec 21 '11 at 23:17
5

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)
Community
  • 1
  • 1
Heinrich Apfelmus
  • 11,039
  • 1
  • 35
  • 66
  • 1
    Well, in the case of `Widget`, having only one field was not a simplification, it's my actual situation, so no tuples are involved :) Thanks for the help, though — it should be very helpful in the future! I'll put the `Behavior` inside the newtype for now. I wish I could accept both answers :) – ehird Dec 24 '11 at 13:36