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

In a few recent posts, I’ve been writing about a new basis for functional reactive programming (FRP), embodied in the Reactive library. In those posts, events and reactive values are (first class) values. A reactive system able to produce outputs from inputs might have type Event a -> Event b or perhaps Reactive a -> Reactive b.

Although I’m mostly happy with the simplicity and expressiveness of this new formulation, I’ve also been thinking about arrow-style formulations, as in Fruit and Yampa. Those systems expose signal functions in the programming interface, but relegate events and time-varying values (called “behaviors” in Fran and “signals” in Fruit and Yampa) to the semantics of signal functions.

If you’re not familiar with arrows in Haskell, you can find some getting-started information at the arrows page.

This post explores and presents a few arrow-friendly formulations of reactive systems.

Edits:

• 2008-02-06: Cleaned up the prose a bit.
• 2008-02-09: Simplified chatter-bot filtering.
• 2008-02-09: Renamed for easier topic recognition (was “Invasion of the composable Mutant-Bots”).
• 2008-02-10: Replaced comps by the simpler concatMB for sequential chatter-bot composition.

Stream-bots

Let’s look at some possibilities for formulating reactive systems. The simplest formulation we might try is a function that maps an input stream to output stream. Fortunately, Ross Paterson’s arrows package comes with an arrow transformer that adds stream inputs and outputs to any arrow. The instance definitions are very like MapTrans in Arrows and computation.

newtype StreamArrow (~>) b c = Str (Stream b ~> Stream c)

instance Arrow (~>) => Arrow (StreamArrow (~>)) where ...

In our case, the function arrow suffices:

type StreamBot = StreamArrow (->)

Let’s assume for now that every input triggers exactly one output. In a while, we’ll see that this assumption is easily relaxed, so there’s really no loss of generality.

Other classes

Although, the main attraction is the Arrow interface, Let’s look at some other classes as well.

Functor and Applicative

Functor and Applicative instances for StreamBot i are immediate because StreamBot is an arrow.¹ Therefore, for stream-bots,

fmap :: (b -> c) -> StreamBot a b -> StreamBot a c

pure  :: o -> StreamBot i o
(<*>) :: StreamBot i (a -> b) -> StreamBot i a -> StreamBot i b

These interfaces may sometimes be convenient in place of the Arrow interface.

What semantics do we get from the Functor and Applicative instances?

• In fmap f bot, f gets applied to each output of bot
• In pure x, each input triggers an x out.
• In fbot <*> xbot, the same input stream is passed to each of fbot and xbot. The functions coming out of fbot are applied to the corresponding arguments coming out of xbot.

Note: the semantics of (<*>) is very different from (<*>) on events in the Reactive library, as described in Reactive values from the future. Events work like lists, while bots work like streams.

Monad

I don’t know if there’s a useful or practical Monad instance for StreamBot i that is consistent with the Applicative instance (i.e., with ap == (<*>)). I think each new bot to come out of (>>=) or join would have to be fed the same, full input stream, which would lead to a tremendous time-space leaks.

Monoid

Applicative functors (AFs) give rise to monoids through lifting. A general declaration would be

instance (Applicative f, Monoid o) => Monoid (f o) where
    mempty  = pure   mempty
    mappend = liftA2 mappend

Such an instance would overlap tremendously, but you can use it as a template. For example (using f = StreamArrow (~>) i),

instance Monoid o => Monoid (StreamArrow (~>) i o) where
    mempty  = pure   mempty
    mappend = liftA2 mappend

which applies to stream-bots as a special case.

So, mappend runs two bots in parallel, giving them the same inputs and combining each pair of outputs with mappend (on output values). Of course, it only works when the output type in a monoid.

Mutant-bots

So far we’ve assumed that every input triggers exactly one output. This assumption is critical in ensuring that (<*>) combines functions and arguments resulting from the same input. The same requirement arises with (***) and even first in the Arrow instance.

Unfortunately, the stream-based representation (Stream a -> Stream b) does not statically enforce the one-input-one-output property, i.e., it can represent bots that ignore some inputs and go Chatty-Cathy over others.

We could maintain a feverish vigilance watching for rogue StreamBots, perhaps post guards working in shifts around the clock. But fatigue sets in, and we could never be really confident. Rather than losing sleep, let’s look for a representation that guarantees well-behaved bots.

What representation could we use instead? We want one output per input, so let’s make our bot be a function from a single value, producing a single value. After that input and output, we’d like another opportunity for an input, which would lead to another output and another opportunity for input, and so on:

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

or, in recursive form:

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

As this type definition shows, an input leads a possible bot mutation, as well as an output.

This bot formulation corresponds to a Mealy machine, a classic automaton style for string transducers.

Ross’s arrows package already contains our mutant-bots, again in generalized to an arrow transformer:

newtype Automaton (~>) a b =
    Automaton (a ~> (b, Automaton (~>) a b))

instance Arrow (~>) => Arrow (Automaton (~>)) where ...

Because Automaton is a stream transformer, the Functor, Applicative, and Monoid instances mentioned above for StreamArrow all apply to Automaton as well.

So all that’s left for us is specializing:

type MutantBot = Automaton (->)

Choosy bots

Now that I’ve praised mutant-bots for reliably producing a single output per input, I want to change the rules and drop that restriction. Let’s give our bots freedom to choose whether or not to respond to an input. Then we can formulate things like filtering (as in stream fusion). For instance, a bot might respond only to arrow keys.

Since we just dissed stream-bots for allowing this very freedom, we’ll want to proceed carefully. The stream-bots run all of the outputs together, but our choosy-bots will produce one optional output per input and then mutate. Instead of manufacturing a whole new bot line, we’ll ask the mutant-bots to simulate choosy-bots. Rather than using Maybe directly, we’ll use First, which is a wrapper around Maybe:

newtype ChoosyBot i o = Choosy (MutantBot i (First o))

newtype First a = First (Maybe a)  -- (in Data.Monoid)

Cooperation and disagreements

I mentioned above that MutantBot i is a monoid, in which mappend feeds inputs to two bots and merges their outputs with mappend (on the output type). We’re in luck (or forethought)! Choosy-bots use First o as output, which is a monoid for all o types. Thus we can derive the Monoid implementation automatically, simply by adding “deriving Monoid” to the ChoosyBot definition.

In this derived instance, mempty stays silent, no matter what input, while botA `mappend` botB reacts according to whichever of botA or botB has a response. In case both respond, mappend favors the first bot. To favor botB instead, we could have used Last in place of First in defining ChoosyBot.

Chatter-bots

When merged choosy-bots react to the same input, one response gets lost. The representation itelf insists on picking only one response. Instead of choosing, we can combine responses into a list. The Monoid instance on lists does exactly the combination we want and can be lifted directly to chatter-bots.

newtype ChatterBot i o = Chatter (MutantBot i [o]) deriving Monoid

We still have to show that ChatterBot is an arrow.

instance Arrow ChatterBot where ...

To make an i -> o function into a chatter-bot, just wrap up the outputs as singleton lists (with pure on lists):

  arr h = Chatter (arr (pure . h))

We can build first out of the representation mutant-bot’s first, which makes a MutantBot (a,c) ([bs],c). Just share the c with each b in bs.

  first (Chatter f) = Chatter $
    first f >>> arr ( (bs,c) -> [(b,c) | b <- bs])

The key for sequential composition is an operation that feeds a list of inputs to a mutant-bot and collects the outputs and the final mutant.

steps :: ([i], MutantBot i o) -> ([o], MutantBot i o)
steps (is,bot) =
  first reverse $ foldl step ([], bot) is
 where
   step (os, Automaton f) i = first (:os) (f i)

With this utility, we can define a way to bundle up several multi-responses into one.

concatMB :: MutantBot b [c] -> MutantBot [b] [c]
concatMB bot = Automaton $  bs ->
  (concat *** concatMB) (steps (bs,bot))

The concatMB function is just what we need for sequential chatter-bot composition:

  Chatter ab >>> Chatter bc = Chatter (ab >>> concatMB bc)

Question: can comp be generalized beyond lists? If so, maybe we could unify and generalize choosy- and chatter-bots.

I like these chatter-bots so much that I’m giving them a prettier name:

type (:->) = ChatterBot

Filtering

Chatter-bots can filter out values to which they don’t want to respond. One simple means is analogous to filter on lists, taking a predicate saying which elements to keep:

filterC :: (a -> Bool) -> a :-> a

Another filtering tool consumes Maybe values:

justC :: Maybe a :-> a

Each Nothing gets dropped, and the Just constructors are stripped off what’s left. The implementation is very simple. The underlying mutant-bot converts Nothing with [] and Just a with [a]. Luckily, there’s a standard function for that conversion.

justC = Chatter (arr maybeToList)

It’s then easy to define filterC in terms of justC.

filterC p = arr f >>> justC
 where
   f a | p a       = Just a
       | otherwise = Nothing

One could also define justC in terms of filterC.

These two functions correspond to filterMP and joinMaybes discussed in “A handy generalized filter“.

Comparing arrow and non-arrow approaches

Philosophically, I like that the arrow approach formalizes not only the output half of a behavior but also the input (sensory) half. I’ve long believed this formalization offers to solve the spatial/temporal modularity problems of the original Fran (inherited from TBAG). (I experimented with these issues in Fran but didn’t write it up, and I don’t think they’ve been addressed meanwhile. Subject for another post.) It also has implementation benefits.

When using the arrow style, I miss flexibility and compositionity of types. For instance, in Reactive, I can use Reactive a -> Reactive b -> Reactive c for a reactive system with two input sources. As far as I know, arrows force me to encode every interface into a transformation of a single input source to a single output source. In this case, I can use the (un)currying isomorphism and then the isomorphism of (Reactive a, Reactive b) with Reactive (a,b). For events instead of reactive values, that latter isomorphism does not hold. Instead, (Event a, Event b) is isomorphic to Event (Either a b). (Magnus Carlsson noted the mismatch between arrows and fudgets, remarking that “We need arrows that use sums as products”.)

I also miss the flexibility to choose between events and reactive values. Though similar, they have some very useful differences in their instances of Applicative and Monad. For instance, for Event, (<*>) combines all pairs of occurrences (like the list instance), while for Reactive, (<*>) samples the function and argument for the same time (like the function instance).

The bots described above mix some semantics from events and some from reactive values. The synchronous Applicative corresponds to reactive values, while the monoid is like that of Event.

One thing I like a lot about the implementations in this post, compared with Reactive, is that they do not need any concurrency, and so it’s easy to achieve deterministic semantics. I don’t quite know how to do that for Reactive, as mentioned in “Future values via multi-threading.”

Finally, I wonder how efficient these bots are at not reacting to inputs. In Reactive, if an event occurrence gets filtered out, propagation stops. Chatter-bots continue to propagate empty values lists and bot non-mutations.