2

I am still trying to wrap my head around Haskell and FRP. Specifically, I have worked through some examples using reactive-banana package and starting to get FRP.

However, I still don't understand how the event network knows when an input event has occurred. My understanding is that, unlike NodeJS which has an event loop constantly checking for user inputs, FRP utilizes a different framework for "waiting" or "checking" user inputs or external signals.

From my reading, FRP makes time explicit. By coupling time with either an event or behavior, somehow the network always knows when an external stimulus has fired.

I have read many papers by Conal, Hudak, et al. and the explanations are too technical. Please provide less technical explanation.

Thanks for your help.

phage
  • 584
  • 3
  • 17
  • I think most just *cheat* those into their events using *real word IO stuff* - for example [this](https://hackage.haskell.org/package/reactive-banana-sdl-0.2.0/docs/src/Reactive-Banana-SDL.html#runSDLPump) uses SDL-timers to pump in time - from what I understand you use similar things (your usual imperative/async/event-based `IO` stuff) to build your basis (see [here](https://hackage.haskell.org/package/reactive-banana-1.1.0.1/docs/Reactive-Banana-Frameworks.html)) – Random Dev Jun 01 '16 at 13:45
  • I've written a few examples of connecting FRP libraries to real world UI stuff. An [example connecting reactive-banana to GLUT](http://stackoverflow.com/questions/15129677/simpler-alternative-libs-to-reactive-haskell/26112094#26112094) demonstrates firing events from _real world IO stuff_. An [example connecting reactive-banana to gloss](http://stackoverflow.com/a/20677522/414413) demonstrates stepping events in an explicit event loop, but taking a detour through IO to use the existing support in `Reactive.Banana.Frameworks`. – Cirdec Jun 01 '16 at 18:30

1 Answers1

3

It is useful to keep in mind the distinction between FRP, which is concerned with building interesting Events and Behaviors from basic ones, and platform specific "glue code", which provides a collection of basic Events, like the current mouse position or keyboard presses.

In the Reactive-Banana library, this distinction is reflected in the module structure, Reactive.Banana.Combinators is concerned with the first part, while Reactive.Banana.Frameworks is concerned with the second part.

Now, understanding how the second part (basic Events) works is not important for understanding how the first part (FRP) works; in fact, different libraries may make very different implementation choices.

That said, in the Reactive-Banana library, an event network is essentially a huge callback function that registers itself to external event sources (called AddHandler in the library). Whenever one of these external sources call the callback function, the latter will traverse the graph of Event and Behavior in dependency order, perform the necessary updates to internal state, and finally run the actions previously registered with reactimate.

The magic of FRP is that the library user doesn't see any of these implementation details, though it is sometimes useful to know that "event network = a huge callback function".

Heinrich Apfelmus
  • 11,034
  • 1
  • 39
  • 67
  • Thank Heinrich for respond. I have learned much from your work. Much appreciated. I have a follow-up question. You refer to the flow and interconnection between events and behaviors as an event-network. Is this same as a graph? – phage Jun 06 '16 at 21:03
  • @phage Yes, they essentially mean the same thing. I do make a slight distinction: I usually use "graph" to refer to the Events, Behaviors and their connections, and "network" to refer to this *in conjunction* with the IO actions and registered event handlers. In other words, I think of the former as "pure" and the latter as "impure". But it's really just a small distinction in nomenclature that I like to make to add a tad more precision when writing about it. – Heinrich Apfelmus Jun 07 '16 at 08:52