What Chris King describes is exactly what most imperative videogames do: everything happens in the “now”, and if you want to keep track of history, you need to use a “history” (aka delay or memory) function explicitly.

As you mentioned before, imperative systems indeed don’t have the problem of past input being accumulated, since they use mutable variables. Since that gives plenty of side effects, the standard simulation approach is introducing two “world immutable state frames”, one for the current time and for the “earliest” future as determined by the time of the global earliest event occurrence. The two frames are “swapped”, so only one mutable reference cell actually exists. just as in Haskell, when combined parts of these frames don’t change, they can just be copied-by-reference to the next frame. I guess this basically is what Fruit and Yampa tried to mimic with Arrows: don’t make signals/behaviors/events first class values, so nobody can make a strong reference to the head of the stream; in a sense, signal functions only get to see the current “frame”. As you mentioned, systems like Yampa, Fruit and of course surely the imperative ones don’t give the same notational advantage as one usually gets with Haskell. I’m curious how Reactive will evolve to tackle this nasty dilemma.

Also if I recall correctly in Yampa one had to mark all outputs as strict otherwise lazy evaluation will create a space/time leak again in case the outputs are not observed. This can be problematic when e.g. computing only bounding boxes of deformed geometry for doing visual surface elimination: ideally you don’t want to compute the deformed geometry if the bounding boxes are not visible, but in Yampa, this won’t work I guess since the non-strict deformed geometry would cause a space/time leak…

Other systems like Autodesk’s Maya combine push/pull by having a push system that marks all intermediate and output values that depend on a changed input “dirty”, so that a “pull” of the dirty outputs only re-evaluates those intermediate values that need updating.

Regarding push versus pull, I feel that in practice one must perform runtime profiling of a reactive application to figure out where in the dependency graph one needs to push or pull, as you can’t determine statically how often event sources will trigger.

Other game developers (among I believe Tim Sweeney) have done interesting experiments with the software transactional memory to approach reactive behaviors (often called just AI in games ;): let every behavior “run” on its own thread, using STM variables to read/write the “current” state of other behaviors, retrying when read variables are overwritten by other behaviors during the atomic “update”. Since behaviors in general have few dependencies between them, this approach would scale massively, and when the CPU gets more cores, the system gets faster and faster without having to change the code at all

I wonder what the reactive code using STM in Haskell would like like…

Your switcher, upon receipt at time T of an event carrying some behavior, starts behaving at time T as that behavior behaved at time 0 … hence the space-time leak. OK, so why not define switcher to instead behave at time T as the switched-in behavior behaved at … time T?

The semantics of switcher is exactly what you are suggesting it be, rather than what you thought it is. The tricky part is that world contains information for times earlier than T, so there can be quite a lot of catching up to do.

Is there a paper that defines the semantics of OCamlRT?