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’ »
: http://haskell.org/haskellwiki/Reactive "Wiki page for the Reactive library"
: http://conal.net/blog/posts/reactive-values-from-the-future/ "Blog post: "Reactive values from the future""
: http://conal.net/blog/posts/reactive-normal-form/ "Blog post: "Reactive normal form""
: http://conal.net/blog/posts/blending-continuity-into-reactive-values "Blog post: "Blending continuity into reactive values""
: http://haskell.org/arrows "Arrows: A General Interface to Computation"
: http://www.haskell.org/yale/papers/haskellworkshop01/index.html "Paper: "Genuinely Functional User Interfaces""
: ...
15th January 2008, 09:15 pm
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’ »
: http://haskell.org/haskellwiki/Reactive "Reactive"
: http://conal.net/blog/posts/future-values-via-multi-threading/ "Blog post: "Future values via multi-threading""
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 ...
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 and its application to GUI programming. There's a "Talk page" link for discussion.
I'm also very interested in suggestions and (better yet) ...
