17th February 2008, 09:40 pm
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’ »
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...
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...
9th February 2008, 09:47 pm
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...
25th January 2008, 06:52 pm
For quite a while, I’ve been using a handy operation for filtering functional events:
justE :: Event (Maybe a) -> Event a
The idea of justE is to drop the Nothing-valued occurrences and strip off the Just constructors from the remaining occurrences. Recently I finally noticed the similarity with a standard function (in Data.Maybe):
catMaybes :: [Maybe a] -> [a]
Continue reading ‘A handy generalized filter’ »
For quite a while, I’ve been using a handy operation for filtering functional events: justE :: Event (Maybe a) -> Event a The idea of justE is to drop the...
25th January 2008, 03:13 pm
25th January 2008, 03:00 pm
25th January 2008, 01:56 pm
I’ve gotten interested lately in revisiting functional reactive programming (FRP). I was never entirely satisfied with the semantics or implementation in my original Fran formulation or in its successors. Over the last year, I’ve enjoyed getting more interface and functionality from standard type classes, and I’ve realized that quite a lot of FRP could be both packaged and implemented by leveraging those classes. This post describes that packaging, and in particular shows how the Monad interface makes some operations very easy to define. I suspect that monadic functional reactivity is a very powerful structuring tool with lovely applications.
At ICFP 07, I had a conversation with Mike Sperber about FRP and about his FRP-based Lula system for stage lighting. Mike used blocking threads in Lula, which I had never considered for FRP. While playing with the idea, I realized that I could give a very elegant and efficient solution to caching, unlike my previous FRP implementations, including the recent DataDriven library. From there, I stumbled on the idea of reactive normal form and separating out an aspect of reactivity into the notion of future values. A third new (to me) idea is to factor out continuity from reactivity, so that reactive behaviors arise by composing orthogonal notions of reactive values and non-reactive functions of continuous time.
Two previous posts presented future values, first describing interface and semantics and then a multi-threaded implementation. This post builds a simple foundation for FRP on top of future values, as part of a library Reactive.
Continue reading ‘Reactive values from the future’ »
I’ve gotten interested lately in revisiting functional reactive programming (FRP). I was never entirely satisfied with the semantics or implementation in my original Fran formulation or in its successors. Over...
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...