In Functional reactive partner dancing, I mentioned that (a) the partially applied leading and following types have boilerplate Applicative instances, and (b) the leading type corresponds to varying (reactive) values. Today I realized that those boilerplate instances are not very useful, and that they do not correspond to the Applicative instance of Reactive. In this post, I give a useful Applicative instance that does correspond to the Reactive instance. The instance definition is expressed in terms of the pair editor bot shown at the end of the “dancing” post, which seems to have a variety of applications.

The Applicative instance has one awkward aspect that suggests a tweak to the formulation of leading. I give simplified versions of pair editing and Applicative for the revised type. This change is in version 0.1 of the Bot libary.

Edit 2008-02-15: added FRP tags; prose tweak.

Oops

The multi-output versions of leading and following are formulated simply as the single-output versions, with a list-valued output type:

newtype a :-> b = Follows (Follow a [b])
newtype a :>- b = Leads   (Lead   a [b])

Partially applied, each of these types is a sort of composition of type constructors. For instance, (:->) a is the type composition of Follow a and []. Since both of those type constructors are applicative functors, there are standard definitions of Functor and Applicative.

instance Functor ((:->) i) where
  fmap f (Follows z) = Follows ((fmap.fmap) f z)

instance Applicative ((:->) i) where
  pure x                  = Follows ((pure.pure) x)
  Follows f <*> Follows x = Follows (liftA2 (<*>) f x)

and similarly for (:>-) i.

In fact, these instance templates are abstracted into instances for the type composition operator (:.) found in TypeCompose, so we can get the four instances for free if we define

type (:->) a = Follow a :. []
type (:>-) a = Lead   a :. []

While the Functor instances work fine, the rub (which I didn’t realize when writing the “dancing” post) is that the Applicative instances are not what I want. They delegate to the Applicative instances for Follow a and for []. The result is that each output of lf <*> lx is the list of f x for all f in the (list-valued) lf output at that point and all x in the (list-valued) lx output. In particular, the lf <*> lx will have an output only when both lf and lx have simultaneous outputs.

Instead, I’d like lf <*> lx to have an output whenever either lf or lx has an output. If lf has an output f, I want to output f x, where x is the most recent lx output. Similarly, if lx has an output, I want to output f x, where f is the most recent lf output. This behavior is exactly how Applicative works for Reactive, as described in reactive-normal-form.

A solution and a problem

At the end of Functional reactive partner dancing, I showed a tool that is related to the desired Applicative behavior.

editPairF :: (c,d) -> Either c d :-> (c,d)

Given an initial pair, editPairF accepts replacements of either the first or second element and produces updated pairs, remembering the previous values. Since memory is involved, editPairL is defined in terms of the generic accumulation combinator accumF.

Let’s put editPairF to work, to pair up two follows into a pair-valued follow. A new pair is output whenever either element gets output.

pairF :: (b,c) -> a:->b -> a:->c -> a:->(b,c)
pairF bc ab ac = (Left <$> ab) `mappend` (Right <$> ac) >>> editPairF bc

We had to supply the initial pair here, because follows don’t have initial values. Leads do, however, so the lead-pairing function has a simpler-looking type:

pairL :: a:>-b -> a:>-c -> a:>-(b,c)

The definition of pairL works in terms of pairF. The extra work involves disassembling and reassembling leads into and from initial values and follows.

ab `pairL` ac =
  leads (liftA2 (,) bs cs) $ pairF (b,c) abf acf
 where
   (bs,abf) = splitL ab
   (cs,acf) = splitL ac
   -- Oh dear.  b & c might not be well-defined
   b = last bs
   c = last cs

The awkward bit here is that, as formulated, a multi-lead (a :>- b) could have multiple values even initially. For that reason, I (a) use a cross product (liftA2 (,)) for the initial pairs, and (b) extract a single value from each lead to use in the pair-valued lead’s initial value. This second consideration is worse than awkward; it will fail if either initial value list is empty.

Is it really useful for a lead to have an initial list of values? Not that I know of. I allowed the flexibility because it made the type definitions so simple and uniform, which I’ve found has a decisive impact on the simplicity of code that works on the type.

Placing the initial-list problem aside for now, here is the simple and useful Applicative instance for leads. The pure method makes a lead with an initial value an no future reponses. The (<*>) method uses pairL above to make a lead whose outputs are function/argument pairs, and then maps uncurried function application onto the pairs to get out the results.

instance Applicative ((:>-) i) where
  pure x    = leads [x] mempty
  lf <*> lx = uncurry ($) <$> (lf `pairL` lx)

What about (:->) (following)? I don’t think an Applicative instance like the leading one can exist, due to lack of initial values. Perhaps there is an Applicative instance corresponding to the one on Event (combining all pairs of occurrences over time).

A tweak, and we’re back to safe & elegant

The difficulty with pairL comes from a feature of dubious value, namely having an initial list of values rather than exactly one initial value. Let’s consider removing that flexibility. Replace

newtype a :>- b = Leads (Lead a [b])

with

newtype a :>- b = Leads (b, a :-> b)

The pairing combinator for leads is now simpler. It’s also bomb-proof, since it has initial single values instead of lists:

pairL :: a:>-b -> a:>-c -> a:>-(b,c)
Leads (a,fa) `pairL` Leads (b,fb) =
  Leads ((a,b), pairF (a,b) fa fb)

And we have simple and (I think) trouble-free instances:

instance Functor ((:>-) i) where
  fmap f (Leads (b,fol)) = Leads (f b, fmap f fol)

instance Applicative ((:>-) i) where
  pure x    = Leads (x,mempty)
  lf <*> lx = uncurry ($) <$> (lf `pairL` lx)

This note continues an exploration of arrow-friendly formulations of functional reactive programming. I refine the previous representations into an interactive dance with dynamically interchanging roles of follow and lead. These two roles correspond to the events and reactive values in the (non-arrow) library Reactive described in a few previous posts. The post ends with some examples.

The code described (with documentation and examples) here may be found in the new, experimental library Bot (which also covers mutant-bots and chatter-bots).

Dancing with Mealy machines

As mentioned in a previous post, Mealy-style automata (“bots”) can be given the following type:

a -> (b, a -> (b, a -> (b, ...)))

where a and b are the types of inputs and outputs, respectively. The essence of Mealy machines is the alternation of consuming and producing values. The type ensures that exactly one output is delivered per input. In recursive form,

newtype a `MutantBot` b = Mutant (a -> (b, a `MutantBot` b))

which is a special case of Ross Paterson’s Automaton arrow transformer.

These bots do nothing until prompted by an external partner. What kind of thing is that partner? Unlike our bots, it must have the ability to take initiative, i.e., to produce a value without itself being prompted. So we might say that the partner is leading, while the bot is following (or acting and reacting, or generative and receptive).

Once the partner has provided a value, the bot can then provide a reponse. After the bot’s reponse, there will be another value from the partner. Once this dance has begun, the roles of lead and follow are no longer static but rather trade back and forth fluidly.

We’ve seen the type of the bot:

a -> (b, a -> (b, a -> (b, ...)))

What is the type of the partner who can dance Lead to the bot’s Follow? Initially, while the bot waits for a value (follows), the partner provides one (leads). After that first step, the roles reverse.

(a, b -> (a, b -> (a, b -> ...)))

This Lead type matches the range of the Follow type, but with a and b swapped. We can therefore type our bot friend as a `Follow` b and its partner as b `Lead` a, where

type a `Follow` b =  a -> Lead a b
type a `Lead`   b = (b, Follow a b)

This formulation makes it clear that the bot and the partner are simply different phases of the same kind of process (though with swapped type parameters). While the bot is a `Follow` b, the partner is b `Lead` a; and while the bot is a `Lead` b, the partner is b `Follow` a.

Haskell won’t accept these mutually recursive types without at least one newtype or data wrapper. We’ll use two.

newtype a `Follow` b = Follow (a -> Lead a b)
newtype a `Lead`   b =   Lead (b, Follow a b)

Aside: I studied partner dancing pretty intensively a few years ago, during my mid-life sabbatical. One of my later teachers rocked my conception of dancing when he said that the roles of “lead” and “follow” are not rigid, but alternate fluidly between the parters. For instance the man (typically) initiates a movement (leads), which the woman (typically) responds to (follows). The roles then smoothly reverse: the man then follows her as she leads him through completion of the movement, when the roles reverse again.

Class instances

Partially applied, both of these types are functors and applicative functors.

instance Functor (Follow a) where
  fmap f (Follow h) = Follow (fmap f . h)

instance Applicative (Follow a) where
  pure b = Follow (const (pure b))
  Follow h <*> Follow k = Follow $  a -> h a <*> k a

instance Functor (Lead a) where
  fmap f (Lead (b, g)) = Lead (f b, fmap f g)

instance Applicative (Lead a) where
  pure b = Lead (b, pure b)
  Lead (f,pf) <*> Lead (a,pa) = Lead (f a, pf <*> pa)

Since I’ve been playing with Functor and Applicative and type compositions a lot lately, some patterns in this code jump out at me. It’s almost possible to get these four instances automatically, from very simple reformulations of Follow and Lead. I’ll address those reformulations in another post.

An Arrow instance for Follow can be adapted easily from the Arrow instance for Automaton. I don’t think it’s possible to define an Arrow instance for Lead, however. Is it an instance of some other generic notion?

The type parameter order for Follow and Lead is always received before generated. That order fits well with the type classes Functor, Applicative, and Arrow, while the reversed parameter order would mesh with contra-variant functors. However, Control.Arrow provides its own contravariant map (and related goodies):

-- | Precomposition with a pure function.
(^>>) :: Arrow (~>) => (b -> c) -> c ~> d -> b ~> d
f ^>> a = arr f >>> a

By the way, I prefer infix operators over the traditional form (e.g., c ~> d vs a c d). Keep in mind that “->” binds less strongly than other infix operators.

Events and varying values

One of the puzzles I’ve had about arrow-based reactivity is how to distinguish between events and reactive values. The lead/follow dance provides an answer. Here are the definitions, from Reactive values from the future.

newtype Event b = Future (Reactive b)

data Reactive b = Stepper b (Event b)

An event starts out in waiting mode–a sort of pregnant phase–until it gives birth to a reactive value. A reactive value initially has a value and then acts like an event. These two definitions are very like our Follow and Lead. Where Event and Reactive use futures, the arrow-based formulations have explicit inputs (of type a).

Now that I have this follow/lead perspective, I regret my choice of the name “Reactive” for varying values. Now I see that events are initially reactive (receptive), while varying values are initially active (generative).

Getting chatty

I’ve found it useful to allow any number of outputs in reaction to a single input. In particular, filtering eliminates outputs, and mappend can combine outputs. This flexibility motivated chatter-bots. The implementation is simple: use a list-valued output type, rewrapping as another abstraction.

newtype a :>- b = Leads   (Lead   a [b])
newtype a :-> b = Follows (Follow a [b])

These types are also functors and applicative functors (when partially applied). The instances are boilerplate for any composition of applicative functors. The Arrow instance is a straightforward adaption from the ChatterBot instance given in Functional reactive chatter-bots.

The Lead and Follow types are very similar to Fudgets-style stream processors, which provide output flexibility in a different way. I will compare these two approaches in an upcoming post.

Examples

The examples from Accumulation for functional reactive chatter-bots all work in the lead/follow setting, with changes to the function names. Those examples were follows, but are more useful as leads, which we can now do as well, thanks to lead versions of the accumulating combinators.

As another example, let’s maintain the product of two independently-changing numbers. In Reactive, we’d take two reactive (varying) values and return one:

Reactive Int -> Reactive Int -> Reactive Int

We’ll have to re-arrange this interface to fit into the Arrow-style interface. As described earlier, a reactive value is simply a value and an event (analogous to a lead and a follow). A bit of currying, argument flipping, and uncurrying gives the type

(Int,Int) -> (Event Int, Event Int) -> Reactive Int

Next use the Event/pairing isomorphism:

(Int,Int) -> Event (Either Int Int) -> Reactive Int

which converts to a Lead:

prod :: (Int,Int) -> Either Int Int :>- Int

As first step, let’s decode the Either-valued input into a pair-modifying function

updPair :: Either c d -> (c,d) -> (c,d)
updPair (Left  c') (_,d) = (c',d)
updPair (Right d') (c,_) = (c,d')

Or, the functionally svelte

updPair = (first.const) `either` (second.const)

Using updPair, we can convert the Either-encoded pair edits to editing functions, and then cumulatively apply those functions. (The accumF function is like accumC on chatter-bots.)

editPairF :: (c,d) -> Either c d :-> (c,d)
editPairF cd = updPair ^>> accumF cd

We have all we need to make a Lead version of pair editing as well:

editPairL :: (c,d) -> Either c d :>- (c,d)
editPairL cd = leads [cd] (editPairF cd)

Or, with some pointfree-fu,

    editPairL = leads.pure <*> editPairF

where leads is a convenience function:

leads :: [b] -> a :-> b -> a :>- b
leads bs (Follows fol) = Leads (Lead (bs,fol))

Our prod example is now just a simple application of these generally useful pair editors.

prod = (fmap.fmap) (uncurry (*)) editPairL

The first fmap is for (->) (Int,Int), and the second is for (:>-) (Either Int Int).