Editorial Hi functional programmers,
As functional programming becomes more popular and people search for more declarative ways of expressing programs, it is only natural to wonder how immutable values and referentially transparent functions can be used to develop interactive systems. Even a fully reified notion of time is not enough to allow for the uncertainty of the timing and value of events.
How does one model the value of a system at a specific time? Can such a model be manipulated formally, as in an algebra, to be reasoned about mathematically? How can continuous functions of time be combined with discreet events? And how does one reason about an uncertain future?
Functional Reactive Programming (FRP) is a specific formalism of a model of behaviors that change in response to events, created by Conal Elliot. That's a pretty abstract statement, but FRP is abstract itself. It does not denote a particular implementation, but rather a formal semantics. It is not a style of programming or a paradigm. It's simply a formalism. And it is an answer to those hard questions.
FRP has caught my eye as an elegant means of modeling state over time in an easily composable way. I also find it to be incredibly inspiring. The notion that approaching the problem conceptually and developing a formal semantics first can lead to better optimization potential and frankly simpler implementations has gotten me to dig deeper into many of my programs and find much simpler and more elegant representations and implementations.
Let me say that again:
Functional Reactive Programming (and Denotational Design, also by Conal Elliott) has a lot to teach us about how to design functional programs.
- Easier to reason about
- Simpler to implement
- Easier to optimize
While the full variety of FRP material is much larger than I cite here, these materials will get you started.
Eric Normand <firstname.lastname@example.org> @ericnormand
PS Learn more about the Clojure Gazette and subscribe. Learn about advertising in the Gazette.