In a previous post, I presented a fundamental reason why classic FRP does not fit interactive behavior, which is that the semantic model captures only the influence of time and not other input. I also gave a simple alternative, with a simple and general model for temporal and spatial transformation, in which input behavior is transformed inversely to the transformation of output behavior.

The semantic model I suggested is the same as used in “Arrow FRP”, from Fruit and Yampa. I want, however, a more convenient and efficient way to package up that model, which is the subject of the post you are reading now.

Next, we took a close look at one awkward aspect of classic FRP for interactive behavior, namely the need to trim inputs, and how trimming relates to comonadic FRP. The trim function allows us to define multi-phase interactive behaviors correctly and efficiently, but its use is tedious and is easy to get wrong. It thus fails to achieve what I want from functional programming in general and FRP in particular, which is to enable writing simple, natural descriptions, free of mechanical details.

The current post hides and automates the mechanics of trimming, so that the intent of an interactive behavior can be expressed directly and executed correctly and efficiently.

As before, I’ll adopt two abbreviations, for succinctness:

type B = Behavior
type E = Event

Safe and easy trimming

Previously, I defined an interactive cat behavior as follows:

cat3 :: B World -> B Cat
cat3 world = sleep world `switcher`
               ((uncurry prowl <$> trimf wake   world) `mappend`
                (uncurry eat   <$> trimf hunger world))

I’d really like to write the following

-- ideal:
cat4 = sleep `switcher` ((prowl <$> wake) `mappend` (eat <$> hunger)) 

Let’s see how close we can get.

I can see right off I’ll have to replace or generalize switcher. For now, I’ll replace it:

switcherf :: (B i -> B o)
          -> (B i -> E (B i -> B o))
          -> (B i -> B o)

This function will have to manage trimming:

bf `switcherf` ef =  i ->
  bf i `switcher` (uncurry ($) <$> trimf ef i)

I won’t have to replace mappend, since it’s a method and so can have a variety of types. In this case, mappend applies to a function from behaviors to events. Fortunately, the function monoid is exactly what we need:

instance Monoid b => Monoid (a -> b) where
  mempty        = const mempty
  f `mappend` g =  a -> f a `mappend` f b

or the more lovely standard form for applicative functors:

instance Monoid b => Monoid (a -> b) where
  mempty  = pure   mempty
  mappend = liftA2 mappend

The use of (<$>) (i.e., fmap) in cat4 above won’t work. We want instead to fmap inside the result of a function from behaviors to events. Using the style of semantic editor combinators, we get the following definition, which is fairly close to our ideal:

cat4 = sleep `switcherf`
         ((result.fmap) prowl wake `mappend` (result.fmap) eat hunger)

Generalized switching

To generalize switcher, introduce a new type class:

class Switchable b e where switcher :: b -> e b -> b

The original Reactive switcher is a special case:

instance Switchable (B a) E where switcher = R.switcher

We can switch among tuples and among other containers of switchables. For instance,

instance (Functor e, Switchable b e, Switchable b' e)
      => Switchable (b,b') e where
  (b,b') `switcher` e = ( b  `switcher` (fst <$> e)
                        , b' `switcher` (snd <$> e) )

Temporal values

Looking through the examples above, all we really had to do with the input behavior was to compute all remainders. I used

duplicate :: B a -> B (B a)

More generally,

class Temporal a where remainders :: a -> B a

Behaviors and events are included as a special case,

instance Temporal (B a) where remainders = duplicate

instance Temporal (E a) where remainders = ...

Temporal values combine without losing their individuality, which allows efficient change-driven evaluation as in Simply efficient functional reactivity:

instance (Temporal a, Temporal b) => Temporal (a,b) where
  remainders (a,b) = remainders a `zip` remainders b

Similarly for other triples and other data structures.

Sometimes it’s handy to carry static information along with dynamic information. Static types can be made trivially temporal:

instance Temporal Bool where remainders = pure
instance Temporal Int  where remainders = pure
-- etc

With this Temporal class, the trimming definitions above have more general types.

trim  :: Temporal i => E o -> i -> E (o, i)

trimf :: Temporal i => (i -> E o) -> (i -> E (o, i))

As does function switching:

switcherf :: (Temporal i, Switchable o E) =>
             (i -> o) -> (i -> E (i -> o)) -> i -> o

Types for functional interactive behavior

We’ve gotten almost to my ideal cat definition. We cannot, however, use switcher or (<$>) here with functions from behaviors to behaviors, because the types don’t fit.

To cross the last gap, let’s define new types corresponding to the idioms we’ve seen repeatedly above.

-- First try
type i :~> o = BI (B i -> B o)
type i :-> o = EI (B i -> E o)

Or, using type composition:

-- Second try
type (:~>) i = (->) (B i) :. B
type (:->) i = (->) (B i) :. E

The advantage of type composition is that we get some useful definitions for free, including Functor and Applicative instances.

However, there’s a problem with both versions. They limit us to a single behavior as input. A realistic interactive environment has many inputs, including a mixture of behaviors and events.

In Yampa, that mixture is combined into a single behavior, leading to two difficulties:

• The distinction between behaviors and events gets lost, as well as (I think) accurate and minimal-latency event detection and response.
• The bundled input environment changes whenever any component changes, leading to everything getting recomputed and redisplayed when anything changes.

To avoid these problems, I’ll take a different approach. Generalize inputs from behaviors to arbitrary Temporal values, which include behaviors, events and tuples and structures of temporal values.

The types for interactive behaviors and interactive events are

type (:~>) i = (->) i :. B
type (:->) i = (->) i :. E

So i :~> o is like i -> B o, and i :-> o is like i -> E o.

Switching for interactive behaviors wraps the switcherf function from above:

instance Temporal i => Switchable (i :~> o) ((:->) i) where
  switcher = inO2 $  bf ef -> bf `switcherf` (result.fmap) unO ef

The inO2 and unO functions from TypeCompose just manipulate newtype wrappers. See Prettier functions for wrapping and wrapping.

This definition is actually more general than the type given here. For instance, it can be used to switch between interactive events as well as interactive behaviors. To see the generalization, first abstract out the commonality between (:~>) and (:->):

type i :->. f = (->) i :. f

type (:~>) i = i :->. B
type (:->) i = i :->. E

The same instance code but with a more general type:

instance (Temporal i, Switchable (f o) E)
      => Switchable ((i :->. f) o) ((:->) i) where
  switcher = inO2 $  bf ef -> bf `switcherf` (result.fmap) unO ef

We can also switch between interactive collections of behaviors and events, though not with the (:->.) wrapping.

Where are we?

Almost all of the pieces are in place now. Another post will relate input trimming to the time transformation of interactive behaviors, as discussed in Why classic FRP does not fit interactive behavior. Also, how interactive FRP relates to Sequences, segments, and signals.

This post takes a close look at one awkward aspect of classic (non-arrow) FRP for interactive behavior, namely the need to trim (or “age”) old input. Failing to trim results in behavior that is incorrect and grossly inefficient.

Behavior trimming connects directly into the comonad interface mentioned in a few recent posts, and is what got me interested in comonads recently.

In absolute-time FRP, trimming has a purely operational significance. Switching to relative time, trimming is recast as a semantically familiar operation, namely the generalized drop function used in two recent posts.

In the rest of this post, I’ll adopt two abbreviations, for succinctness:

type B = Behavior
type E = Event

Trimming inputs

An awkward aspect of classic FRP has to do with switching phases of behavior. Each phase is a function of some static (momentary) input and some dynamic (time-varying) input, e.g.,

sleep :: B World -> B Cat
eat   :: Appetite   -> B World -> B Cat
prowl :: Friskiness -> B World -> B Cat

wake   :: B World -> E Friskiness
hunger :: B World -> E Appetite

As a first try, our cat prowls upon waking and eats when hungry, taking into account its surrounding world:

cat1 :: B World -> B Cat
cat1 world = sleep world `switcher`
               ((flip prowl world <$> wake   world) `mappend`
                (flip eat   world <$> hunger world))

The (<$>) here, from Control.Applicative, is a synonym for fmap. In this context,

(<$>) :: (a -> B Cat) -> E a -> E (B Cat)

The FRP switcher function switches to new behavior phases as they’re generated by an event, beginning with a given initial behavior:

switcher :: B a -> E (B a) -> B a

And the mappend here merges two events into one, combining their occurrences.

When switching phases, we generally want the new phase to start responding to input exactly where the old phase left off. If we’re not careful, however, the new phase will begin with an old input. I’ve made exactly this mistake in defining cat1 above. Consequently, each new phase will begin by responding to all of the old input and then carry on. This meaning is both unintended and is very expensive (the dreaded “space-time” leak).

This difficulty is not unique to FRP. In functional programming, we have to be careful how we hold onto our inputs, so that they can get accessed and freed incrementally. I don’t think the difficulty arises much in imperative programming, because input (like output) is destructively altered, and programs have access only to the current state.

I’ve done it wrong above, in defining cat. How can I do it right? The solution/hack I came up for Fran was to add a function that trims (“ages”) dynamic input while waiting for event occurrences.

trim :: B b -> E a -> E (a, B b)

trim b e follows b and e in parallel. At each occurrence of e, the remainder of b is paired up with the event data from e.

Now I can define the interactive, multi-phase behavior I intend:

cat2 :: B World -> B Cat
cat2 world = sleep world `switcher`
               ((uncurry prowl <$> trim world (wake   world)) `mappend`
                (uncurry eat   <$> trim world (hunger world)))

The event trim world (wake world) occurs whenever wake world does, and has as event data the cat’s friskiness on waking, plus the remainder of the cat’s world at the occurrence time. The “uncurry prowl <$>” applies prowl to each friskiness and remainder world on waking. Similarly for the other phase.

I think this version defines the behavior I want and that it can run efficiently, assuming that trim e b traverses e and b in parallel (so that laziness doesn’t cause a space-time leak). However, this definition is much trickier than what I’m looking for.

One small improvement is to abstract a trimming pattern:

trimf :: (B i -> E o) -> (B i -> E (o, B i))
trimf ef i = trim i (ef i)

cat3 :: B World -> B Cat
cat3 world = sleep world `switcher`
               ((uncurry prowl <$> trimf wake   world) `mappend`
                (uncurry eat   <$> trimf hunger world))

A comonad comes out of hiding

The trim functions above look a lot like snapshotting of behaviors:

snapshot  :: B b -> E a -> E (a,b)

snapshot_ :: B b -> E a -> E b

Indeed, the meanings of trimming and snapshotting are very alike. They both involving following an event and a behavior in parallel. At each event occurrence, snapshot takes the value of the behavior at the occurrence time, while trim takes the entire remainder from that time on.

Given this similarlity, can one be defined in terms of the other? If we had a function to “extract” the first defined value of a behavior, we could definesnapshot via trim.

b `snapshot` e = fmap (second extract) (b `trim` e)

extract :: B a -> a

We can also define trim via snapshot, if we have a way to get all trimmed versions of a behavior — to “duplicate” a one-level behavior into a two-level behavior:

b `trim` e = duplicate b `snapshot` e

duplicate :: B a -> B (B a)

If you’ve run into comonads, you may recognize extract and duplicate as the operations of Comonad, dual to Monad‘s return and join. It was this definition of trim that got me interested in comonads recently.

In the style of Semantic editor combinators,

snapshot = (result.result.fmap.second) extract trim

or

trim = argument remainders R.snapshot

The extract function is problematic for classic FRP, which uses absolute (global) time. We don’t know with which time to sample the behavior. With relative-time FRP, we’ll only ever sample at (local) time 0.

Relative time

So far, the necessary trimming has strong operational significance: it prevents obsolete reactions and the consequent space-time leaks.

If we switch from absolute time to relative time, then trimming becomes something with familiar semantics, namely drop, as generalized and used in two of my previous posts, Sequences, streams, and segments and Sequences, segments, and signals.

The semantic difference: trimming (absolute time) erases early content in an input; while dropping (relative time) shifts input backward in time, losing the early content in the same way as drop on sequences.

What’s next?

While input trimming can be managed systematically, doing so explicitly is tedious and error prone. A follow-up post will automatically apply the techniques from this post. Hiding and automating the mechanics of trimming allows interactive behavior to be expressed correctly and without distraction.

Another post will relate input trimming to the time transformation of interactive behaviors, as discussed in Why classic FRP does not fit interactive behavior.

In functional reactive programming (FRP), the type we call “behaviors” model non-interactive behavior. To see why, just look at the semantic model: t -> a, for some notion t of time.

One can argue as follows that this model applies to interactive behavior as well. Behaviors interacting with inputs are functions of time and of inputs. Those inputs are also functions of time, so behaviors are just functions of time. I held this perspective at first, but came to see a lack of composability.

My original FRP formulations (Fran and its predecessors TBAG and ActiveVRML), as well as the much more recent library Reactive, can be and are used to describe interactive behavior. For simple sorts of things, this use works out okay. When applications get a bit richer, the interface and semantics strain. If you’ve delved a bit, you’ll have run into the signs of strain, with coping mechanisms like start times, user arguments and explicit aging of inputs, as you avoid the dreaded space-time leaks.

Behaviors

Suppose I define an object that pays attention to an input that’s interesting near a certain time. For instance, a cat chasing a bird in the back yard one morning last week. Now shift the behavior a week forward to this morning. The result is just a week-delayed form of the earlier behavior, displaying reactions to week-old input. The original interactive behavior (the cat) was fed input (bird and yard) from a week ago, the result was recorded, and that recording is replayed a week later.

Written functionally,

laterObserveCat :: Behavior World -> Behavior Cat
laterObserveCat = later week . cat

where

world :: Behavior World
cat   :: Behavior World -> Behavior Cat

later :: Duration -> Behavior a -> Behavior a

We can also sit in the living room, five meters north of the back yard, and watch the cat via a camera.

livingRoomObserveCat :: Behavior World -> Behavior Cat
livingRoomObserveCat = north (5 * meter) . cat

Typically recordings are moved both in space and in time. For example, record the cat in the back yard one week and watch the recording in the living room a week later:

replayLRL :: Behavior World -> Behavior Cat
replayLRL = later week . north (5 * meter) . cat

Interactive behavior

I’ve just described transforming a non-interactive behavior (recording) in time and space. That non-interactive behavior resulted applying an interactive behavior (the cat) to some input (bird and yard). An interactive behavior is simply a function from non-interactive behavior (time-varying input) to non-interactive behavior (time-varying output).

Consider what it means to transform an interactive behavior in space. I pick up the cat and carry her five meters north, into the living room. The cat has a different perspective, which is that her environment moves five meters south. For instance, the mouse that was one meter south of her is now six meters sounth.

If I lift the cat four feet above the ground, she sees the ground now four below her. If I spin her clockwise, her environment spins counter-clockwise. If I point my shrinking ray at her, she sees her world as growing larger, and she flees from the giant mice.

We can play the perspective game in time as well as space. I point my speed-up ray at the cat, and she perceives her environment slow down.

When I say I move the cat north and she see her environment move south, I am not suggesting that there are two alternative perspectives and we might take either one. Rather, a complete picture combines both movements. The behavior my cat exhibits when I pick her up is composed of three transformations:

• The world moves south;
• The cat perceives this more southerly world and responds to it; and
• The resulting cat behavior is moved north.

Written functionally,

livingRoomCat :: Behavior World -> Behavior Cat
livingRoomCat = north (5 * meter) . cat . south (5 * meter)

Similarly with other spatial transformation, each with paired inverse transformations. And similarly in time, e.g.,

laterCat :: Behavior World -> Behavior Cat
laterCat = later week . cat . earlier week

So there’s a semantically consistent model of transforming interactive behaviors in time or space, and this model explains the difference between transformation of non-interactive behavior and of interactive behavior.

Aside

Comparing these two definitions with the previous two suggests an alternative implementation. Refactoring,

laterCat :: Behavior World -> Behavior Cat
laterCat = laterObserveCat . earlier week

Instead of carrying the interactive cat a week ahead in time, this definition suggests that we move the world (other than the cat) back one week, record the cat interacting with it, and hold onto that recording to watch a week later. My back-of-the-envelope calculations suggest that this second implementation is less resource-efficient than the first one, so I’ll not consider it further in this post.

Arrow FRP

When we use for an interactive setting the tools suited to non-interactive behaviors, we’re begging for space leaks (filling up recording media) and time leaks (fast-forwarding through old recorded matter to catch up with what we want to see). These problems are what people experience when programming explicitly with might call “classic FRP”, i.e., programming explicitly with (non-interactive) behaviors. Out of this experience was born “Arrow FRP”, as in Fruit and Yampa. The idea of Arrow FRP was to program with a type of “signal functions”, which can be thought of as mappings between behaviors:

type SF a b = Behavior a -> Behavior b

(Behaviors were also renamed to “signals”, but I’ll stick with “behaviors” for now.) We can just look at semantic model for signal transformers and see that they’re about interactive behavior.

A lot of work was done with this new model, mostly growing out of Paul Hudak’s group at Yale. It addressed the inherent awkwardness of the explicit-behavior style.

Despite this fundamental advantage of signal transformers, why am I still fooling around with the “classic” (pre-arrow) style?

• The Arrow style required multiple behaviors to be bunched up into one. That combination appears to thwart efficient, change-driven evaluation, which was the problem I tackled in Simply efficient functional reactivity.
• There was no room for the distinction between behaviors and events. I’d love to see how to combine them without losing expressiveness or semantic accuracy, and I haven’t yet.
• Arrow programming is very awkward without the special arrow notation and has more of a sequential style than I like with the arrow notation. I missed the functional feel of classic FRP.

Coming up

Given the fundamental semantic fit between signal transformers for the problem domain of interactive behavior, I’d like to come up wh convenient and efficient packaging. The next posts will describe the packaging I’m trying out now.