How fundamentally different are push-pull and arrowized FRP?

Question

I want to study FRP in Haskell, but it's a bit difficult to decide on a library to use. Many seem to be dead attempts, some seem to have been resurrected (such as recent activity on Yampa).

From what I read, it seems that there are two "kinds" of FRP: push-pull FRP (like in Reactive-banana and Reflex) on one side and arrowized FRP (like in Yampa) on the other side. It seems that there also used to be some "classic FRP" at the time of Fran and FrTime, but I have not spotted any recent activity in these.

• Are these two (or three) really fundamentally different approaches of FRP?

• Is one of them outdated theory whereas the other would be the "stuff of the future"?

• Or do they have to evolve in parallel, addressing different purposes?

• Did I name the most prominent library of each category, or are there other options to consider (Sodium, Netwire, et al)?

---

_{I finally watched the [talk from Evan Czaplicki](https://www.youtube.com/watch?v=Agu6jipKfYw) recommended in the comments by J. Abrahamson. It is very interesting and did help clarify things up for me. I highly recommend it to anyone who found this question interesting.}

Tantalic

You might be interested in ertes' (the netwire author's) opinion: https://mcmap.net/q/110784/-what-39-s-the-status-of-current-functional-reactive-programming-implementations – Daryldaryle

Really quickly: reactive-banana is definitely pull-based not push-pull. reactive is push-pull. Yampa and netwire are arrowized. There are FRPs which allow "accumulating values" but don't allow "switching", FRPs which allow "switching" but not "accumulating values". Both of those are "simple" FRP. Arrowized FRP allows switching and accumulating and uses arrows to control the danger of combining those features. Monadic FRP like reactive-banana, sodium, and elerea use other careful mechanisms to ensure that switching and accumulating don't interact too much. – Gameness

Arrowized FRP also has the neat feature that signals are always stated in context of their inputs which lets you transform the outputs covariantly and the inputs contravariantly in order to better simulate interactive FRP. See Genuinely Functional User Interfaces by Courtney and Elliott for a great example of that feature. – Gameness

You might also be interested in the talk "Controlling Time and Space" by Elm author Evan Czaplicki. In my opinion he manages to give a good high level overview over the FRP design space and the compromises involved. – Wildebeest

Thanks J. Abrahamson and DanielM for your comments. – Tantalic

I think you will get your answer here.. #10000574 – Quiroz

@J.Abrahamson Just wanted to note, that reactive-banana doesn't have a monadic but an applicative interface. – Wilks

@Wilks The basic API is applicative, yes, but the Switching API introduces the monad. I admit its a different kind than Sodium/Elerea, though. – Gameness

Perhaps you can define an acronym the first time you use it (FRP). – Nucleotidase

@J.Abrahamson According to hackage, reactive-banana is push-based, not pull-based... – Casimir

While the question makes sense in the context of the FRP reality, I still think that it mixes two distinct concept: the programming interface variant of an FRP library and the implementation techniques & optimizations that are easy (or at all possible) with a given programming interface variant. I would say that the two main FRP programming interface variants are monadic and arrowized and the pull / push / push-pull / paralell / ... are implementation techniques & optimizations. – Ri

From what I'v read, it seems to me that push-pull implementation technique might be easier with the monadic interface, but the monadic interface combined with non-strictness has time leak issues. The arrowized interface seems to be implementable without time leak issues, but maybe it's more difficult to implement the push-pull there? I'm still not sure about these bits. – Ri

Answer 1

I took a trip to Haskell.org to investigate your question What I found are two important papers you ought to read to further your research, and I am building my answer to your question from these scholarly papers.

Push-Pull FRP by Conal Elliott

Generalising Monads to Arrows by John Hughes

---

1. Yes, but also no. According to Elliot, push is data driven FRP evaluation and pull relates to what is called "demand" driven evaluation. The author recommends pull because push tends to idle in between data inputs. Here's the crux: push-pull combines and balances these behaviors for the chief purpose of minimizing the need to recompute values. It's simple; operating FRP with push-pull hastens the ability to react. Arrow is a different technique for using abstract types to link values and evaluate them simultaneously. All these concepts are fundamentally different. But don't take my word for it:

   The nature of the Arrow interface is problematic for the goal of minimal re-evaluation. Input events and behaviors get combined into a single input, which then changes whenever any component changes, (Elliott).

   Thus, Arrow contradicts the goal of push-pull. That does not mean you can't use all of these at once, just that it would be complex, and there are some things you cannot compute without abstract Arrow types.

2. I have not found scholarly opinions on which approaches are "the way of the future." Only note that arrows can handle simultaneity particularly well. If you could implement arrows and use push-pull to minimize computations, that would be the way of the future.

3. Yes, they address separate purposes. As I said, they can be formulated together but it is difficult to implement and even if it does work, it would probably negate the reactive speed benefits of push-pull.

4. That's subjective, but Reactive and Yampa appear to be the most commonly cited language libraries for FRP. I would say Reactive by Conal Elliott has deep roots, and Yampa is established as well. Other projects like Netwire arose as replacements, but it could be awhile before they replace the giants.

---

Hope this helps! Like I said reading the articles I pointed out will give you a better sense of the semantic distance between arrow, push and pull.

Popularity