8th April 2008, 08:22 pm

When I first started playing with functional reactivity in Fran and its predecessors, I didn’t realize that much of the functionality of events and reactive behaviors could be packaged via standard type classes.
Then Conor McBride & Ross Paterson introduced us to *applicative functors*, and I remembered using that pattern to reduce all of the lifting operators in Fran to just two, which correspond to `pure`

and `(< *>)`

in the `Applicative`

class.
So, in working on a new library for functional reactive programming (FRP), I thought I’d modernize the interface to use standard type classes as much as possible.

While spelling out a precise (denotational) semantics for the FRP instances of these classes, I noticed a lovely recurring pattern:

The meaning of each method corresponds to the same method for the meaning.

In this post, I’ll give some examples of this principle and muse a bit over its usefulness.
For more details, see the paper *Simply efficient functional reactivity*.
Another post will start exploring type class morphisms and type composition, and ask questions I’m wondering about.

Continue reading ‘Simplifying semantics with type class morphisms’ »

When I first started playing with functional reactivity in Fran and its predecessors, I didn’t realize that much of the functionality of events and reactive behaviors could be packaged via...

4th April 2008, 02:27 pm

I submitted a paper *Simply efficient functional reactivity* to ICFP 2008.

**Abstract:**

Functional reactive programming (FRP) has simple and powerful semantics, but has resisted efficient implementation. In particular, most past implementations have used demand-driven sampling, which accommodates FRP’s continuous time semantics and fits well with the nature of functional programming. Consequently, values are wastefully recomputed even when inputs don’t change, and reaction latency can be as high as the sampling period.

This paper presents a way to implement FRP that combines data- and demand-driven evaluation, in which values are recomputed only when necessary, and reactions are nearly instantaneous. The implementation is rooted in a new simple formulation of FRP and its semantics and so is easy to understand and reason about.

On the road to efficiency and simplicity, we’ll meet some old friends (monoids, functors, applicative functors, monads, morphisms, and improving values) and make some new friends (functional future values, reactive normal form, and concurrent “unambiguous choice”).

I submitted a paper Simply efficient functional reactivity to ICFP 2008. Abstract: Functional reactive programming (FRP) has simple and powerful semantics, but has resisted efficient implementation. In particular, most past...

Tags:

applicative functor,

continuous,

discrete,

events,

FRP,

functional reactive programming,

functor,

future value,

icfp,

implementation,

joinMaybes,

monad,

monoid,

multi-threading,

normal form,

paper,

reactive behavior,

reactive value,

semantics,

time,

type class,

type class morphism,

type composition |

33 Comments
12th February 2008, 10:30 pm

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.

Continue reading ‘Applicative bots’ »

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

11th February 2008, 10:16 pm

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

Continue reading ‘Functional reactive partner dancing’ »

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

5th February 2008, 10:22 pm

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.

Continue reading ‘Functional reactive chatter-bots’ »

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

15th January 2008, 09:15 pm

## Future values

A previous post described future values (or simply “futures”), which are values depend on information from the future, e.g., from the real world. There I gave a simple denotational semantics for future values as time/value pairs. This post describes the multi-threaded implementation of futures in Reactive‘s `Data.Reactive`

module.

Continue reading ‘Future values via multi-threading’ »

Future values A previous post described future values (or simply “futures”), which are values depend on information from the future, e.g., from the real world. There I gave a simple...

15th January 2008, 05:31 pm

A *future value* (or simply “future”) is a value that might not be knowable until a later time, such as “the value of the next key you press”, or “the value of LambdaPix stock at noon next Monday” (both from the time you first read this sentence), or “how many tries it will take me to blow out all the candles on my next birthday cake”. Unlike an imperative computation, each future has a unique value — although you probably cannot yet know what that value is. I’ve implemented this notion of futures as part of a library Reactive.

**Edits**:

- 2008-04-04: tweaked tag; removed first section heading.

Continue reading ‘Future values’ »

A future value (or simply “future”) is a value that might not be knowable until a later time, such as “the value of the next key you press”, or “the...

2nd June 2007, 10:58 am

I would love to get comments on a short (4.5 page) paper draft called “Applicative Data-Driven Computation” (Haskell wiki page), which describes a very simple approach to data-driven (push-based) computation and its application to GUI programming. There’s a “Talk page” link for discussion.

I’m also very interested in suggestions and (better yet) collaboration on other applications of data-driven computation beyond GUIs, say push-based internet apps.

I would love to get comments on a short (4.5 page) paper draft called “Applicative Data-Driven Computation” (Haskell wiki page), which describes a very simple approach to data-driven (push-based) computation...