Inspirations & experiments, mainly about denotative/functional programming in Haskell
Archive for January 2008
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]
This post continues from “Reactive values from the future” and “Reactive normal form”.
Fran/FRP reactive behaviors could change continuously, while reactive values change only discretely. The Reactive library keeps continuity orthogonal to reactivity. To combine continuity and reactivity, simply compose reactivity with a non-reactive type of functions of time.
Continue reading ‘Blending continuity into reactive values’ »
The post “Reactive values from the future” presented a simple formulation of functional events and reactive values, built on a functional notion of future values. In the current post, I’ll describe some of the implementation of events and reactive values*.
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.
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.
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:
I gave up on Blogger, where I’d been keeping my technical blog. Blogger was removing one leading space per line of pre-formatted html (“code”) on every edit/preview cycle.
Meanwhile, I’ve been enjoying using Markdown, so I poked aroud and found a WordPress solution I think I’ll like for a while. You’re looking at it.
The steps are described in a post on Syntax highlighting with Markdown in WordPress. It uses a combination of PHP Markdown Extra and GeSHi (Generic Syntax Highlighter), plus a small extension to specify which language for a block of code. It works great. I tweaked the PHP code to make the default language be Haskell instead of txt. The GeSHi-decorated code even has links to library documentation, which I love.
I had a bit of trouble along the way and got help on the #wordpress IRC channel. It turned out that I hadn’t followed the installation directions for PHP Markdown Extra, which say to move markdown.php out of its directory directly into my plugins directory. Once I knew to look in the Apache error log, it was pretty easy to track down the problem.
Still to do:
Data.Monoid, Control.Applicative, and Control.Arrow.I’d like to hear from anyone who is happy with their blogging engine’s treatment of code. I use Blogger, and it strips leading spaces from each line of my code on every edit/preview pass. I lose alignment, and eventually, all the code ends up at the left margin.