Ever since ActiveVRML, the model we’ve been using in functional reactive programming (FRP) for interactive behaviors is
(T->a) -> (T->b), for dynamic (time-varying) input of type
a and dynamic output of type
T is time).
In “Classic FRP” formulations (including ActiveVRML, Fran & Reactive), there is a “behavior” abstraction whose denotation is a function of time.
Interactive behaviors are then modeled as host language (e.g., Haskell) functions between behaviors.
Problems with this formulation are described in Why classic FRP does not fit interactive behavior.
These same problems motivated “Arrowized FRP”.
In Arrowized FRP, behaviors (renamed “signals”) are purely conceptual.
They are part of the semantic model but do not have any realization in the programming interface.
Instead, the abstraction is a signal transformer,
SF a b, whose semantics is
(T->a) -> (T->b).
See Genuinely Functional User Interfaces and Functional Reactive Programming, Continued.
Whether in its classic or arrowized embodiment, I’ve been growing uncomfortable with this semantic model of functions between time functions. A few weeks ago, I realized that one source of discomfort is that this model is mostly junk.
This post contains some partially formed thoughts about how to eliminate the junk (“garbage collect the semantics”), and what might remain.
There are two generally desirable properties for a denotational semantics: full abstraction and junk-freeness. Roughly, “full abstraction” means we must not distinguish between what is (operationally) indistinguishable, while “junk-freeness” means that every semantic value must be denotable.
FRP’s semantic model,
(T->a) -> (T->b), allows not only arbitrary (computable) transformation of input values, but also of time.
The output at some time can depend on the input at any time at all, or even on the input at arbitrarily many different times.
Consequently, this model allows respoding to future input, violating a principle sometimes called “causality”, which is that outputs may depend on the past or present but not the future.
In a causal system, the present can reach backward to the past but not forward the future. I’m uneasy about this ability as well. Arbitrary access to the past may be much more powerful than necessary. As evidence, consult the system we call (physical) Reality. As far as I can tell, Reality operates without arbitrary access to the past or to the future, and it does a pretty good job at expressiveness.
Moreover, arbitrary past access is also problematic to implement in its semantically simple generality.
There is a thing we call informally “memory”, which at first blush may look like access to the past, it isn’t really. Rather, memory is access to a present input, which has come into being through a process of filtering, gradual accumulation, and discarding (forgetting). I’m talking about “memory” here in the sense of what our brains do, but also what all the rest of physical reality does. For instance, weather marks on a rock are part of the rock’s (present) memory of the past weather.
A very simple memory-less semantic model of interactive behavior is just
a -> b.
This model is too restrictive, however, as it cannot support any influence of the past on the present.
Which leaves a question: what is a simple and adequate formal model of interactive behavior that reaches neither into the past nor into the future, and yet still allows the past to influence the present? Inspired in part by a design principle I call “what would reality do?” (WWRD), I’m happy to have some kind of infinitesimal access to the past, but nothing further.
My current intuition is that differentiation/integration plays a crucial role. That information is carried forward moment by moment in time as “momentum” in some sense.
I call intuition cosmic fishing. You feel a nibble, then you’ve got to hook the fish. – Buckminster Fuller
Where to go with these intuitions?
Perhaps interactive behaviors are some sort of function with all of its derivatives.
See Beautiful differentiation for an specification and derived implementation of numeric operations, and more generally of
Applicative, on which much of FRP is based.
I suspect the whole event model can be replaced by integration. Integration is the main remaining piece.
How weak a semantic model can let us define integration?
My thanks to Luke Palmer and to Noam Lewis for some clarifying chats about these half-baked ideas. And to the folks on #haskell IRC for brainstorming titles for this post. My favorite suggestions were
- luqui: instance HasJunk FRP where
- luqui: Functional reactive programming’s semantic baggage
- sinelaw: FRP, please take out the trash!
- cale: Garbage collecting the semantics of FRP
- BMeph: Take out the FRP-ing Trash
all of which I preferred over my original “FRP is mostly junk”.