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.

The post Sequences, streams, and segments offered an answer to the the question of what’s missing in the following box:

I presented a simple type of function segments, whose representation contains a length (duration) and a function. This type implements most of the usual classes: Monoid, Functor, Zip, and Applicative, as well Comonad, but not Monad. It also implements a new type class, Segment, which generalizes the list functions length, take, and drop.

The function type is simple and useful in itself. I believe it can also serve as a semantic foundation for functional reactive programming (FRP), as I’ll explain in another post. However, the type has a serious performance problem that makes it impractical for some purposes, including as implementation of FRP.

Fortunately, we can solve the performance problem by adding a simple layer on top of function segments, to get what I’ll call “signals”. With this new layer, we have an efficient replacement for function segments that implements exactly the same interface with exactly the same semantics. Pleasantly, the class instances are defined fairly simply in terms of the corresponding instances on function segments.

You can download the code for this post.

Edits:

• 2008-12-06: dup [] = [] near the end (was [mempty]).
• 2008-12-09: Fixed take and drop default definitions (thanks to sclv) and added point-free variant.
• 2008-12-18: Fixed appl, thanks to sclv.
• 2011-08-18: Eliminated accidental emoticon in the definition of dup, thanks to anonymous.

The problem with function segments

The type of function segments is defined as follows:

data t :-># a = FS t (t -> a)

The domain of the function segment is from zero up to but not including the given length.

An efficiency problem becomes apparent when we look at the Monoid instance:

instance (Ord t, Num t) => Monoid (t :-># a) where
    mempty = FS 0 (error "sampling empty 't :-># a'")
    FS c f `mappend` FS d g =
      FS (c + d) ( t -> if t <= c then f t else g (t - c))

Concatenation (mappend) creates a new segment that chooses, for every domain value t, whether to use one function or another. If the second, then t must be shifted backward, since the function is being shifted forward.

This implementation would be fine if we use mappend just on simple segments. Once we get started, however, we’ll want to concatenate lots & lots of segments. In FRP, time-varying values go through many phases (segments) as time progresses. Each quantity is described by a single “behavior” (sometimes called a “signal”) with many, and often infinitely many, phases. Imagine an infinite tree of concatenations, which is typical for FRP behaviors. At every moment, one phase is active. Every sampling must recursively discover the active phase and the accumulated domain translation (from successive subtractions) to apply when sampling that phase. Quite commonly, concatenation trees get progressively deeper on the right (larger t values). In that case, sampling will get slower and slower with time.

I like to refer to these progressive slow-downs as “time leaks”. There is also a serious space leak, since all of the durations and functions that go into a composed segment will be retained.

Sequences of segments

The problem above can be solved with a simple representation change. Instead of combining functions into functions, just keep a list of simple function segments.

-- | Signal indexed by t with values of type a.
newtype t :-> a = S { unS :: [t :-># a] }

I’ll restrict in function segments to be non-empty, to keep the rest of the implementation simple and efficient.

This new representation allows for efficient monotonic sampling of signals. As old segments are passed up, they can be dropped.

What does it mean?

There’s one central question for me in defining any data type: What does it mean?

The meaning I’ll take for signals is function segments. This interpretation is made precise in a function that maps from the type to the model (meaning). In this case, simply concatenate all of the function segments:

meaning :: (Ord t, Num t) => (t :-> a) -> (t :-># a)
meaning = mconcat . unS

Specifying the meaning of a type gives users a working model, and it defines correctness of implementation. It also tells me what class instances to implement and tells users what instances to expect. If a type’s meaning implements a class then I want the type to as well. Moreover, the type’s intances have to agree with the model’s instances. I’ve described this latter principle in Simplifying semantics with type class morphisms and some other posts.

Higher-order wrappers

To keep the code below short and clear, I’ll use some functions for adding and removing the newtype wrappers. These higher-order function apply functions inside of (:->) representations:

inS  :: ([s :-># a] -> [t :-># b])
     -> ((s :->  a) -> (t :->  b))

inS2 :: ([s :-># a] -> [t :-># b] -> [u :-># c])
     -> ((s :->  a) -> (t :->  b) -> (u :->  c))

Using the trick described in Prettier functions for wrapping and wrapping, the definitions are simpler than the types:

inS  = result   S . argument unS
inS2 = result inS . argument unS

Functor

The Functor instance applies a given function inside the function segments inside the lists:

instance Functor ((:->) t) where
    fmap h (S ss) = S (fmap (fmap h) ss)

Or, in the style of Semantic editor combinators,

instance Functor ((:->) t) where
    fmap = inS . fmap . fmap

Why this definition? Because it is correct with respect to the semantic model, i.e., the meaning of fmap is fmap of the meaning, i.e.,

 meaning . fmap h == fmap h . meaning

which is to say that the following diagram commutes:

Proof:

meaning . fmap h 

  == {- fmap definition -}

meaning . S . fmap (fmap h) . unS

  == {- meaning definition -}

mconcat . unS . S . fmap (fmap h) . unS

  == {- unS and S are inverses  -}

mconcat . fmap (fmap h) . unS

  == {- fmap h distributes over mappend -}

fmap h . mconcat . unS

  == {- meaning definition -}

fmap . meaning

Applicative and Zip

Again, the meaning functions tells us what the Applicative instance has to mean. We only get to choose how to implement that meaning correctly. The Applicative morphism properties:

meaning (pure a)    == pure a
meaning (bf <*> bx) == meaning bf <*> meaning bx

Our Applicative instance has a definition similar in simplicity and style to the Functor instance, assuming a worker function appl for (<*>):

instance (Ord t, Num t, Bounded t) => Applicative ((:->) t) where
    pure  = S . pure . pure
    (<*>) = inS2 appl

appl :: (Ord t, Num t, Bounded t) =>
        [t :-># (a -> b)] -> [t :-># a] -> [t :-># b]

This worker function is somewhat intricate. At least my implementation of it is, and perhaps there’s a simpler one.

Again, the meaning functions tells us what the Applicative instance has to mean. We only get to choose how to implement that meaning correctly.

First, if either segment list runs out, the combination runs out (because the same is true for the meaning of signals).

[] `appl` _  = []

_  `appl` [] = []

If neither segment list is empty, open up the first segment. Split the longer segment into a prefix that matches the shorter segment, and combine the two segments with (<*>) (on function segments). Toss the left-over piece back in its list, and continue.

(fs:fss') `appl` (xs:xss')
   | fd == xd  = (fs  <*> xs ) : (fss' `appl`       xss' )
   | fd <  xd  = (fs  <*> xs') : (fss' `appl` (xs'':xss'))
   | otherwise = (fs' <*> xs ) : ((fs'':fss') `appl` xss')
 where
   fd         = length fs
   xd         = length xs
   (fs',fs'') = splitAt xd fs
   (xs',xs'') = splitAt fd xs

A Zip instance is easy as always with applicative functors:

instance (Ord t, Num t, Bounded t) => Zip ((:->) t) where zip = liftA2 (,)

Monoid

The Monoid instance:

instance Monoid (t :-> a) where
  mempty = S []
  S xss `mappend` S yss = S (xss ++ yss)

Correctness follows from properties of mconcat (as used in the meaning function).

We’re really just using the Monoid instance for the underlying representation, i.e.,

instance Monoid (t :-> a) where
    mempty  = S mempty
    mappend = inS2 mappend

Segment

The Segment class has length, take and drop. It’s handy to include also null and splitAt, both modeled after their counterparts on lists.

The new & improved Segment class:

class Segment seg dur | seg -> dur where
    null    :: seg -> Bool
    length  :: seg -> dur
    take    :: dur -> seg -> seg
    drop    :: dur -> seg -> seg
    splitAt :: dur -> seg -> (seg,seg)
    -- Defaults:
    splitAt d s = (take d s, drop d s)
    take    d s = fst (splitAt d s)
    drop    d s = snd (splitAt d s)

If we wanted to require dur to be numeric, we could add a default for null as well. This default could be quite expensive in some cases. (In the style of Semantic editor combinators, take = (result.result) fst splitAt, and similarly for drop.)

The null and length definitions are simple, following from to properties of mconcat.

instance (Ord t, Num t) => Segment (t :-> a) t where
  null   (S xss) = null xss
  length (S xss) = sum (length <$> xss)
  ...

The null case says that the signal is empty exactly when there are no function segments. This simple definition relies on our restriction to non-empty function segments. If we drop that restriction, we’d have to check that every segment is empty:

  -- Alternative definition
  null (S xss) = all null xss

The length is just the sum of the lengths.

The tricky piece is splitAt (used to define both take and drop), which must assemble segments to satisfy the requested prefix length. The last segment used might have to get split into two, with one part going into the prefix and one to the suffix.

  splitAt _ (S [])  = (mempty,mempty)
  splitAt d b | d <= 0 = (mempty, b)
  splitAt d (S (xs:xss')) =
    case (d `compare` xd) of
      EQ -> (S [xs], S xss')
      LT -> let (xs',xs'') = splitAt d xs in
              (S [xs'], S (xs'':xss'))
      GT -> let (S uss, suffix) = splitAt (d-xd) (S xss') in
              (S (xs:uss), suffix)
   where
     xd = length xs

Copointed and Comonad

To extract an element from a signal, extract an element from its first function segment. Awkwardly, extraction will fail (produce ⊥/error) when the signal is empty.

instance Num t => Copointed ((:->) t) where
    extract (S [])     = error "extract: empty S"
    extract (S (xs:_)) = extract xs

I’ve exploited our restriction to non-empty function segments. Otherwise, extract would have to skip past the empty ones:

-- Alternative definition
instance Num t => Copointed ((:->) t) where
    extract (S []) = error "extract: empty S"
    extract (S (xs:xss'))
      | null xs     = extract (S xss')
      | otherwise   = extract xs

The error/⊥ in this definition is dicey, as is the one for function segments. If we allow the same abuse in order to define a list Copointed, we can get an alternative to the first definition that is prettier but gives a less helpful error message:

instance Num t => Copointed ((:->) t) where
    extract = extract . extract . unS

See the closing remarks for more about this diciness.

Finally, we have Comonad, with its duplicate method.

duplicate :: (t :-> a) -> (t :-> (t :-> a))

I get confused with wrapping and unwrapping, so let’s separate the definition into a packaging part and a content part.

instance (Ord t, Num t) => Comonad ((:->) t) where
    duplicate = fmap S . inS dup

with content part:

dup :: (Ord t, Num t) => [t :-># a] -> [t :-># [t :-># a]]

The helper function, dup, takes each function segment and prepends each of its tails onto the remaining list of segments.

If the segment list is empty, then it has only one tail, also empty.

dup []        = []

dup (xs:xss') = ((: xss') <$> duplicate xs) : dup xss'

Closing remarks

• The definitions above use the function segment type only through its type class interfaces, and so can all of them can be generalized. Several definitions rely on the Segment instance, but otherwise, each method for the composite type relies on the corresponding method for the underlying segment type. (For instance, fmap uses fmap, (<*>) uses (<*>), Segment uses Segment, etc.) This generality lets us replace function segments with more efficient representations, e.g., doing constant propagation, as in Reactive. We can also generalize from lists in the definitions above.

• Even without concatenation, function segments can become expensive when drop is repeatedly applied, because function shifts accumulate (e.g., f . (+ 0.01) . (+ 0.01) ....). A more drop-friendly representation for function segments would be a function and an offset. Successive drops would add offsets, and extract would always apply the function to its offset. This representation is similar to the FunArg comonad, mentioned in The Essence of Dataflow Programming (Section 5.2).

• The list-of-segments representation enables efficient monotonic sampling, simply by dropping after each sample. A variation is to use a list zipper instead of a list. Then non-monotonic sampling will be efficient as long as successive samplings are for nearby domain values. Switching to multi-directional representation would lose the space efficiency of unidirectional representations. The latter work well with lazy evaluation, often running in constant space, because old values are recycled while new values are getting evaluated.

• Still another variation is to use a binary tree instead of a list, to avoid the list append in the Monoid instance for (t :-> a). A tree zipper would allow non-monotonic sampling. Sufficient care in data structure design could perhaps yield efficient random access.

• There’s a tension between the Copointed and Monoid interfaces. Copointed has extract, and Monoid has mempty, so what is the value of extract mempty? Given that Copointed is parameterized over arbitrary types, the only possible answer seems to be ⊥ (as in the use of error above). I don’t know if the comonad laws can all hold for possibly-empty function segments or for possibly-empty signals. I’m grateful to Edward Kmett for helping me understand this conflict. He suggested using two coordinated types, one possibly-empty (a monoid) and the other non-empty (a comonad). I’m curious to see whether that idea works out.

What kind of thing is a movie? Or a song? Or a trajectory from point A to point B? If you’re a computer programmer/programmee, you might say that such things are sequences of values (frames, audio samples, or spatial locations). I’d suggest that these discrete sequences are representations of something more essential, namely a flow of continuously time-varying values. Continuous models, whether in time or space, are often more compact, precise, adaptive, and composable than their discrete counterparts.

Functional programming offers great support for sequences of variable length. Lazy functional programming adds infinite sequences, often called streams, which allows for more elegant and modular programming.

Functional programming also has functions as first class values, and when the function’s domain is (conceptually) continuous, we get a continuous counterpart to infinite streams.

Streams, sequences, and functions are three corners of a square. Streams are discrete and infinite, sequences are discrete and finite, and functions-on-reals are continuous and infinite. The missing corner is continuous and finite, and that corner is the topic of this post.

You can download the code for this post.

Edits:

• 2008-12-01: Added Segment.hs link.
• 2008-12-01: Added Monoid instance for function segments.
• 2008-12-01: Renamed constructor “DF” to “FS” (for “function segment”)
• 2008-12-05: Tweaked the inequality in mappend on (t :-># a).

Streams

I’ll be using Wouter Swierstra’s Stream library. A stream is an infinite sequence of values:

data Stream a = Cons a (Stream a)

Stream is a functor and an applicative functor.

instance Functor Stream where
    fmap f (Cons x xs) = Cons (f x) (fmap f xs)

instance Applicative Stream where
    pure  = repeat
    (<*>) = zipWith ($)

repeat :: a -> Stream a
repeat x = Cons x (repeat x)

Comonads

Recently I’ve gotten enamored with comonads, which are dual to monads. In other words, comonads are like monads but wearing their category arrows backwards. I’ll be using the comonad definitions from the category-extras library.

The most helpful intuitive description I’ve found is that comonads describe values in context.

The return method injects a pure value into a monadic value (having no effect).

return  :: Monad m     => a -> m a

The dual to monadic return is extract (sometimes called “counit” or “coreturn“), which extracts a value out of a comonadic value (discarding the value’s context). category-extras library splites this method out from Comonad into the Copointed class:

extract :: Copointed w => w a -> a

Monadic values are typically produced in effectful computations:

a -> m b

Comonadic values are typically consumed in context-sensitive computations:

w a -> b

(Kleisli arrows wrap the producer pattern, while CoKleisli arrows wrap the consumer pattern.)

Monads have a way to extend a monadic producer into one that consumes to an entire monadic value:

(=<<) :: (Monad m) => (a -> m b) -> (m a -> m b)

We more often see this operation in its flipped form (obscuring the conceptual distinction between Haskell arrows and arbitrary category arrows):

(>>=) :: (Monad m) => m a -> (a -> m b) -> m b

Dually, comonads have a way to extend a comonadic consumer into one that produces an entire comonadic value:

extend :: (Comonad w) => (w a -> b) -> (w a -> w b)

which also has a flipped version:

(=>>) :: (Comonad w) => w a -> (w a -> b) -> w b

Another view on monads is as having a way to join two monadic levels into one.

join      :: (Monad   m) => m (m a) -> m a

Dually, comonads have a way to duplicate one level into two:

duplicate :: (Comonad w) => w a -> w (w a)

For a monad, any of join, (=<<), and (>>=) can be used to define the others. For a comonad, any of duplicate, extend, and (=>>) can be used to define the others.

The Stream comonad

What might the stream comonad be?

The Stream library already has functions of the necessary types for extract and duplicate, corresponding to familiar list functions:

head :: Stream a -> a
head (Cons x _ ) = x

tails :: Stream a -> Stream (Stream a)
tails xs = Cons xs (tails (tail xs))

where

tail :: Stream a -> Stream a
tail (Cons _ xs) = xs

Indeed, head and tails are just what we’re looking for.

instance Copointed Stream where extract   = head
instance Comonad   Stream where duplicate = tails

There is also a Monad instance for Stream, in which return is repeat (matching pure as expected) and join is diagonalization, producing a stream whose n^th element is the n^th element of the n^th element of a given stream of streams.

Adding finiteness

Lists and other possibly-finite sequence types add an interesting new aspect over streams, which is concatenation, usually wrapped in a Monoid instance.

class Monoid o where
    mempty  :: o
    mappend :: o -> o -> o

Lists also have take and drop operations, which can undo the effect of concatenation, as well as a notion of length (duration). Let’s generalize these three to be methods of a new type class, Segment, so that we can defined continuous versions.

class Segment seg len where
    length :: seg -> len
    drop   :: len -> seg -> seg
    take   :: len -> seg -> seg

For lists, we can use the prelude functions

instance Segment [a] Int where
    length = Prelude.length
    drop   = Prelude.drop
    take   = Prelude.take

Or the more generic versions:

instance Integral i => Segment [a] i where
    length = genericLength
    drop   = genericDrop
    take   = genericTake

These three functions relate to mappend, to give us the following “Segment laws”:

drop (length as) (as `mappend` bs) == bs
take (length as) (as `mappend` bs) == as

t <= length as ==> length (take t as) == t
t <= length as ==> length (drop t as) == length as - t

Adding continuity

Streams and lists are discrete, containing countably many or finitely many elements. They both have continuous counterparts.

When we think of a stream as a function from natural numbers, then John Reynolds’s alternative arises: functions over real numbers, i.e., a continuum of values. If we want uni-directional streams, then stick with non-negative reals.

Many stream and list operations are meaningful and useful not only for discrete sequences but also for their continuous counterparts.

The infinite (stream-like) case is already handled by the class instances for functions found in the GHC base libraries (Control.Functor.Instances and Control.Applicative).

instance Functor ((->) t) where
    fmap = (.)

instance Applicative ((->) t) where
    pure = const
    (f <*> g) x = (f x) (g x)

instance Monad ((->) t) where
    return = const
    f >>= k =  t -> k (f t) t

As a consequence,

  join f == f >>= id ==  t -> f t t

Assume a type wrapper, NonNeg, for non-negative values. For discrete streams, r == NonNeg Integer, while for continuous streams, r == NonNeg R, for some type R representing reals.

The co-monadic instances from the category-extras library:

instance Monoid o => Copointed ((->) o) where
    extract f = f mempty

instance Monoid o => Comonad ((->) o) where
    duplicate f x =  y -> f (x `mappend` y)

Finite and continuous

Functions provide a setting for generalized streams. How do we add finiteness? A very simple answer is to combine a length (duration) with a function, to form a “function segment”:

data t :-># a = FS t (t -> a)

The domain of this function is from zero to just short of the given length.

Now let’s define class instances.

Exercise: Show that all of the instances below are semantically consistent with the Stream and ZipList instances.

Monoid

Empty function segments have zero duration. Concatenation adds durations and samples either function, right-shifting the second one.

instance (Ord t, Num t) => Monoid (t :-># a) where
    mempty = FS 0 (error "sampling empty 't :-># a'")
    FS c f `mappend` FS d g =
      FS (c + d) ( t -> if t <= c then f t else g (t - c))

Segment

The Segment operations are easy to define:

instance Num t => Segment (t :-># a) t where
    length (FS d _) = d
    drop t (FS d f) = FS (d - t) ( t' -> f (t + t'))
    take t (FS _ f) = FS t f

Notice what’s going on with drop. The length gets shortened by t (the amount dropped), and the function gets shifted (to the “left”) by t.

There’s also a tantalizing resemblance between this drop definition and duplicate for the function comonad. We’ll return in another post to tease out this and

I’ve allowed dropping or taking more than is present, though these cases can be handled with an error or a by taking or dropping fewer elements (as with the list drop and take functions).

Functor, Zip and Applicative

fmap applies a given function to each of the function values, leaving the length unchanged.

instance Functor ((:->#) t) where
    fmap h (FS d f) = FS d (h . f)

zip pairs corresponding segment values and runs out with the shorter segment. (See More beautiful fold zipping for the Zip class.)

instance Ord t => Zip ((:->#) t) where
    FS xd xf `zip` FS yd yf = FS (xd `min` yd) (xf `zip` yf)

pure produces a constant value going forever. (<*>) applies functions to corresponding arguments, running out with the shorter.

instance (Ord t, Bounded t) => Applicative ((:->#) t) where
    pure a = FS maxBound (const a)
    (<*>)  = zipWith ($)

Copointed and Comonad

extract pulls out the initial value (like head).

instance Num t => Copointed ((:->#) t) where
    extract (FS _ f) = f 0

duplicate acts like tails. The generated segments are progressivly dropped versions of the original segment.

instance Num t => Comonad ((:->#) t) where
    duplicate s = FS (length s) (flip drop s)

Monad

I don’t know if there is a monad instance for ((:->#) t). Simple diagonalization doesn’t work for join, since the n^th segment might be shorter than n.

What’s ahead?

The instances above remind me strongly of type class instances for several common types. Another post will tease out some patterns and reconstruct (t :-># a) out of standard components, so that most of the code above can disappear.

Another post incorporates (t :-># a) into a new model and implementation of relative-time, comonadic FRP.