Conal Elliott's FRP formulation

[cubuspl42]

The book states that the FRP presented in it is the one formulated by Conal Elliot. I've just read two Conal Elliot's papers: "Functional Reactive Animation" from the 90's and the more recent one, "Push-pull functional reactive programming". It wasn't an easy read, I must admit. The author has a very strong theoretical background, while I barely parse Haskell.

The older paper felt a bit exotic, probably because it's so old. One of the things that surprised me was that Event was actually... an event, i.e. a single thing happening at some point of time - a single pair (t, a), not a sequence of pairs. It changed in the latter paper to [(t, a)], now being much more similar to Sodium's Stream. The name outdated, though. Why is something representing a sequence of events named Event?

My another observation was that both FRP systems described in the papers there seems to be stateless, samplable at any arbitrary time. Although the second papers says...

In practice, behaviors are rendered forward in time, and so are sampled with monotonically increasing times. Making this usage pattern explicit allows for much more efficient sampling.

...it still defines at :: Behavior a → Ba, but since type Ba = T → a, so in my understanding it implies at :: Behavior a → T → a, same as in the first paper (at : Behavior𝛼 → Time → 𝛼). I read it as "having a behaviour, you can sample it in a pure way for any time t". How can such system handle actual user interaction? I checked how Reactive Banana implements at, and it seems that it is valueB :: MonadMoment m => Behavior a -> m a. It's a monadic interface, so I guess it is related / can be integrated with the IO monad (like I said before, my I'm not proficient at Haskell). Maybe I'm taking things too literally? Maybe the prototypes from the paper aren't ready for using them in implementations?

It seems that Elliot defines a primitive operator, switcher :: Behavior a → Event (Behavior a) → Behavior a, which combines hold and switch from Sodium. It's an interesting choice, I'm wondering if it simplifies things or make them more complex. What was your motivation behind splitting it into hold/switch?

[clinuxrulz]

How can such system handle actual user interaction? . To my understanding it doesn't. The mathemation has their T->mousePos, etc. already predefined to demonstrate the model. Like a prerecording to test the model on.

In Mathematics there are no side effects. And I believe they are providing the mathematical model of FRP, to be understood by other mathematicians. It is by no means how'd you would actually implemented it in the end. Implementing FRP using pure functional programming (just like how the mathematics is completely pure), then your end performance will suffer quiet a bit.

Mathematically to show a value of type a that varies of over time (a mutable variable) is like so T -> a. Its says I'm a pure functions such that if you feed me any wall clock time, then I will give you the value of that variable at that time. (Its just how mathematicians do side effects)

When ever you see T -> a from the mathematicians side, then you generally see IO a on the programmers side (at least in Haskell). The "MomentMonad m", has the capabilities of "IO", except that it also passes additional pumping state throughout the program for doing transactions and for maintaining ranks, listeners (keep alive pool for the strong listeners), etc.

There is no global mutable state in Haskell, so you have to keep passing references to your mutable stage along as the code executes. That is why it is "MomentMonad m" instead of "IO". (To hide the passing of mutable state away from the programmer.)

Since monads and high order generics are god awful to do in most mainstream languages, we have a global state for the transactions and transactions are handled via the Transaction singleton object. It is the imperative solution to the "MomentMonad m".

Just because the machinery under the hood is imperative, does not mean all of SodiumFRP is imperative. Most parts of SodiumFRP's interface are pure in an unobservable side-effects kind of way. (Sort of like you can have local-side effects in functions, and still have those functions behave in a pure way to their external environment.)

What matters is the implementation and mathematics are equivalent in an analog way.

I've honestly never seen switcher before, but I do not believe it will hold any real benefit over Sodium's switchC. Some cases your code might be longer, some cases your code might be sorter. Mileage will vary.