I submitted a paper Simply efficient functional reactivity to ICFP 2008.
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’ve been noodling over a difference between behaviors (functions of time) and events (sequences of time/value pairs). A product of behaviors is isomorphic to a behavior of products, but a product of events is isomorphic to an event of sums.
Ba × Bb ≅ Ba × b
Ea × Eb ≅ Ea + b
A similar property has been noted for Fudgets-like stream processors.
Behaviors (or "reactive values") and events are inter-related. In particular, we can make a behavior from an initial value and an event, using the
stepper function. If we want to use
stepper with a pair value, we’d have to use a pair-valued event. However, it’s often more convenient and efficient to work with pair of separate change events, or (using the event pair/sum isomorphism) a sum-valued event.
This post plays with another perspective on sum types for events and stream processors. It can also apply to bots.
Continue reading ‘Pairs, sums, and reactivity’ »
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.
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’ »
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’ »
In Functional reactive chatter-bots, I described a few arrow-friendly formulations of functional reactive programming (FRP). This post shows how to define accumulation combinators and gives a few simple examples of their use.
Continue reading ‘Accumulation for 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 (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.
- 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’ »