What is functional reactive programming

Question

I ve read the Wikipedia article on reactive programming  I ve also read the small article on functional reactive programming  The descriptions are quite abstract    What does functional reactive programming  FRP  mean in practice   What does reactive programming  as opposed to non-reactive programming   consist of     My background is in imperative OO languages  so an explanation that relates to this paradigm would be appreciated

User · Answer

To me it is about 2 different meanings of symbol      In math x   sin t  means  that x is different name for sin t   So writing x   y is the same thing as sin t    y  Functional reactive programming is like math in this respect  if you write x   y  it is computed with whatever the value of t is at the time it s used  In C-like programming languages  imperative languages   x   sin t  is an assignment  it means that x stores the value of sin t  taken at the time of the assignment

User · Answer

It is about mathematical data transformations over time  or ignoring time    In code this means functional purity and declarative programming   State bugs are a huge problem in the standard imperative paradigm  Various bits of code may change some shared state at different  times  in the programs execution  This is hard to deal with   In FRP you describe  like in declarative programming  how data transforms from one state to another and what triggers it  This allows you to ignore time because your function is simply reacting to its inputs and using their current values to create a new one  This means that the state is contained in the graph  or tree  of transformation nodes and is functionally pure   This massively reduces complexity and debugging time   Think of the difference between A B C in math and A B C in a program   In math you are describing a relationship that will never change  In a program  its says that  Right now  A is B C  But the next command might be B   in which case A is not equal to B C  In math or declarative programming A will always be equal to B C no matter what point in time you ask    So by removing the complexities of shared state and changing values over time  You program is much easier to reason about   An EventStream is an EventStream   some transformation function   A Behaviour is an EventStream   Some value in memory   When the event fires the value is updated by running the transformation function  The value that this produces is stored in the behaviours memory   Behaviours can be composed to produce new behaviours that are a transformation on N other behaviours  This composed value will recalculate as the input events  behaviours  fire    Since observers are stateless  we often need several of them to simulate a state machine as in the drag example  We have to save the state where it is accessible to all involved observers such as in the variable path above    Quote from - Deprecating The Observer Pattern http   infoscience epfl ch record 148043 files DeprecatingObserversTR2010 pdf

User · Answer

Paul Hudak s book  The Haskell School of Expression  is not only a fine introduction to Haskell  but it also spends a fair amount of time on FRP  If you re a beginner with FRP  I highly recommend it to give you a sense of how FRP works   There is also what looks like a new rewrite of this book  released 2011  updated 2014   The Haskell School of Music

User · Answer

If you want to get a feel for FRP  you could start with the old Fran tutorial from 1998  which has animated illustrations   For papers  start with Functional Reactive Animation and then follow up on links on the publications link on my home page and the FRP link on the Haskell wiki   Personally  I like to think about what FRP means before addressing how it might be implemented   Code without a specification is an answer without a question and thus  not even wrong    So I don t describe FRP in representation implementation terms as Thomas K does in another answer  graphs  nodes  edges  firing  execution  etc   There are many possible implementation styles  but no implementation says what FRP is   I do resonate with Laurence G s simple description that FRP is about  datatypes that represent a value  over time     Conventional imperative programming captures these dynamic values only indirectly  through state and mutations  The complete history  past  present  future  has no first class representation  Moreover  only discretely evolving values can be  indirectly  captured  since the imperative paradigm is temporally discrete  In contrast  FRP captures these evolving values directly and has no difficulty with continuously evolving values   FRP is also unusual in that it is concurrent without running afoul of the theoretical  amp  pragmatic rats  nest that plagues imperative concurrency  Semantically  FRP s concurrency is fine-grained  determinate  and continuous   I m talking about meaning  not implementation   An implementation may or may not involve concurrency or parallelism   Semantic determinacy is very important for reasoning  both rigorous and informal  While concurrency adds enormous complexity to imperative programming  due to nondeterministic interleaving   it is effortless in FRP   So  what is FRP  You could have invented it yourself  Start with these ideas    Dynamic evolving values  i e   values  over time   are first class values in themselves   You can define them and combine them  pass them into  amp  out of functions   I called these things  behaviors   Behaviors are built up out of a few primitives  like constant  static  behaviors and time  like a clock   and then with sequential and parallel combination   n behaviors are combined by applying an n-ary function  on static values    point-wise   i e   continuously over time  To account for discrete phenomena  have another type  family  of  events   each of which has a stream  finite or infinite  of occurrences   Each occurrence has an associated time and value  To come up with the compositional vocabulary out of which all behaviors and events can be built  play with some examples   Keep deconstructing into pieces that are more general simple  So that you know you re on solid ground  give the whole model a compositional foundation  using the technique of denotational semantics  which just means that  a  each type has a corresponding simple  amp  precise mathematical type of  meanings   and  b  each primitive and operator has a simple  amp  precise meaning as a function of the meanings of the constituents  Never  ever mix implementation considerations into your exploration process   If this description is gibberish to you  consult  a  Denotational design with type class morphisms   b  Push-pull functional reactive programming  ignoring the implementation bits   and  c  the Denotational Semantics Haskell wikibooks page   Beware that denotational semantics has two parts  from its two founders Christopher Strachey and Dana Scott  the easier  amp  more useful Strachey part and the harder and less useful  for software design  Scott part    If you stick with these principles  I expect you ll get something more-or-less in the spirit of FRP   Where did I get these principles   In software design  I always ask the same question   what does it mean    Denotational semantics gave me a precise framework for this question  and one that fits my aesthetics  unlike operational or axiomatic semantics  both of which leave me unsatisfied   So I asked myself what is behavior  I soon realized that the temporally discrete nature of imperative computation is an accommodation to a particular style of machine  rather than a natural description of behavior itself  The simplest precise description of behavior I can think of is simply  function of  continuous  time   so that s my model  Delightfully  this model handles continuous  deterministic concurrency with ease and grace   It s been quite a challenge to implement this model correctly and efficiently  but that s another story

User · Answer

This article by Andre Staltz is the best and clearest explanation I ve seen so far  Some quotes from the article   Reactive programming is programming with asynchronous data streams  On top of that  you are given an amazing toolbox of functions to combine  create and filter any of those streams   Here s an example of the fantastic diagrams that are a part of the article

User · Answer

After reading many pages about FRP I finally came across this enlightening writing about FRP  it finally made me understand what FRP really is all about    I quote below Heinrich Apfelmus  author of reactive banana       What is the essence of functional reactive programming       A common answer would be that    FRP is all about describing a system in   terms of time-varying functions instead of mutable state     and that   would certainly not be wrong  This is the semantic viewpoint  But in   my opinion  the deeper  more satisfying answer is given by the   following purely syntactic criterion       The essence of functional reactive programming is to specify the dynamic behavior of a value completely at the time of declaration       For instance  take the example of a counter  you have two buttons   labelled    Up    and    Down    which can be used to increment or decrement   the counter  Imperatively  you would first specify an initial value   and then change it whenever a button is pressed  something like this   counter    0                               -- initial value on buttonUp      counter    counter   1    -- change it later on buttonDown    counter    counter - 1        The point is that at the time of declaration  only the initial value   for the counter is specified  the dynamic behavior of counter is   implicit in the rest of the program text  In contrast  functional   reactive programming specifies the whole dynamic behavior at the time   of declaration  like this   counter    Behavior Int counter   accumulate     0              fmap   1  eventUp               union  fmap  subtract 1  eventDown        Whenever you want to understand the dynamics of counter  you only have   to look at its definition  Everything that can happen to it will   appear on the right-hand side  This is very much in contrast to the   imperative approach where subsequent declarations can change the   dynamic behavior of previously declared values    So  in my understanding an FRP program is a set of equations    j is discrete  1 2 3 4     f depends on t so this incorporates the possiblilty to model external stimuli  all state of the program is encapsulated in variables x i  The FRP library takes care of progressing time  in other words  taking j to j 1   I explain these equations in much more detail in this video   EDIT   About 2 years after the original answer  recently I came to the conclusion that FRP implementations have another important aspect  They need to  and usually do  solve an important practical problem  cache invalidation   The equations for x i-s describe a dependency graph  When some of the x i changes at time j then not all the other x i  values at j 1 need to be updated  so not all the dependencies need to be recalculated because some x i  might be independent from x i    Furthermore  x i-s that do change can be incrementally updated  For example let s consider a map operation f g map   1  in Scala  where f and g are List of Ints  Here f corresponds to x i t j  and g is x j t j   Now if I prepend an element to g then it would be wasteful to carry out the map operation for all the elements in g  Some FRP implementations  for example reflex-frp  aim to solve this problem   This problem is also known as incremental computing   In other words  behaviours  the x i-s   in FRP can be thought as cache-ed computations  It is the task of the FRP engine to efficiently invalidate and recompute these cache-s  the x i-s  if some of the f i-s do change

User · Answer

The short and clear explanation about Reactive Programming appears on Cyclejs - Reactive Programming  it uses simple and visual samples       A  module Component object  is reactive means it is fully responsible   for managing its own state by reacting to external events       What is the benefit of this approach  It is Inversion of Control    mainly because  module Component object  is responsible for itself  improving encapsulation using private methods against public ones    It is a good startup point  not a complete source of knowlege  From there you could jump to more complex and deep papers

User · Answer

FRP is a combination of Functional programming programming paradigm built upon the idea of everything is a function  and reactive programming paradigm  built upon the idea that everything is a stream observer and observable philosophy    It is supposed to be the best of the worlds   Check out Andre Staltz post on reactive programming to start with

User · Answer

According to the previous answers  it seems that mathematically  we simply think in a higher order  Instead of thinking a value x having type X  we think of a function x  T   X  where T is the type of time  be it the natural numbers  the integers or the continuum  Now when we write y    x   1 in the programming language  we actually mean the equation y t    x t    1

User · Answer

Disclaimer  my answer is in the context of rx js - a  reactive programming  library for Javascript   In functional programming  instead of iterating through each item of a collection  you apply higher order functions  HoFs  to the collection itself  So the idea behind FRP is that instead of processing each individual event  create a stream of events  implemented with an observable   and apply HoFs to that instead  This way you can visualize the system as data pipelines connecting publishers to subscribers    The major advantages of using an observable are  i  it abstracts away state from your code  e g   if you want the event handler to get fired only for every  n th event  or stop firing after the first  n  events  or start firing only after the first  n  events  you can just use the HoFs  filter  takeUntil  skip respectively  instead of setting  updating and checking counters  ii  it improves code locality - if you have 5 different event handlers changing the state of a component  you can merge their observables and define a single event handler on the merged observable instead  effectively combining 5 event handlers into 1  This makes it very easy to reason about what events in your entire system can affect a component  since it s all present in a single handler       An Observable is the dual of an Iterable     An Iterable is a lazily consumed sequence - each item is pulled by the iterator whenever it wants to use it  and hence the enumeration is driven by the consumer    An observable is a lazily produced sequence - each item is pushed to the observer whenever it is added to the sequence  and hence the enumeration is driven by the producer

User · Answer

Acts like a spreadsheet as noted  Usually based on an event driven framework    As with all  paradigms   it s newness is debatable   From my experience of distributed flow networks of actors  it can easily fall prey to a general problem of state consistency across the network of nodes i e  you end up with a lot of oscillation and trapping in strange loops   This is hard to avoid as some semantics imply referential loops or broadcasting  and can be quite chaotic as the network of actors converges  or not  on some unpredictable state   Similarly  some states may not be reached  despite having well-defined edges  because the global state steers away from the solution  2 2 may or may not get to be 4 depending on when the 2 s became 2  and whether they stayed that way  Spreadsheets have synchronous clocks and loop detection  Distributed actors generally don t   All good fun

User · Answer

I found this nice video on the Clojure subreddit about FRP   It is pretty easy to understand even if you don t know Clojure     Here s the video  http   www youtube com watch v nket0K1RXU4  Here s the source the video refers to in the 2nd half  https   github com Cicayda yolk-examples blob master src yolk examples client autocomplete cljs

User · Answer

OK  from background knowledge and from reading the Wikipedia page to which you pointed  it appears that reactive programming is something like dataflow computing but with specific external  stimuli  triggering a set of nodes to fire and perform their computations   This is pretty well suited to UI design  for example  in which touching a user interface control  say  the volume control on a music playing application  might need to update various display items and the actual volume of audio output  When you modify the volume  a slider  let s say  that would correspond to modifying the value associated with a node in a directed graph   Various nodes having edges from that  volume value  node would automatically be triggered and any necessary computations and updates would naturally ripple through the application   The application  reacts  to the user stimulus  Functional reactive programming would just be the implementation of this idea in a functional language  or generally within a functional programming paradigm   For more on  dataflow computing   search for those two words on Wikipedia or using your favorite search engine  The general idea is this  the program is a directed graph of nodes  each performing some simple computation  These nodes are connected to each other by graph links that provide the outputs of some nodes to the inputs of others   When a node fires or performs its calculation  the nodes connected to its outputs have their corresponding inputs  triggered  or  marked   Any node having all inputs triggered marked available automatically fires  The graph might be implicit or explicit depending on exactly how reactive programming is implemented   Nodes can be looked at as firing in parallel  but often they are executed serially or with limited parallelism  for example  there may be a few threads executing them   A famous example was the Manchester Dataflow Machine  which  IIRC  used a tagged data architecture to schedule execution of nodes in the graph through one or more execution units  Dataflow computing is fairly well suited to situations in which triggering computations asynchronously giving rise to cascades of computations works better than trying to have execution be governed by a clock  or clocks    Reactive programming imports this  cascade of execution  idea and seems to think of the program in a dataflow-like fashion but with the proviso that some of the nodes are hooked to the  outside world  and the cascades of execution are triggered when these sensory-like nodes change  Program execution would then look like something analogous to a complex reflex arc  The program may or may not be basically sessile between stimuli or may settle into a basically sessile state between stimuli    non-reactive  programming would be programming with a very different view of the flow of execution and relationship to external inputs  It s likely to be somewhat subjective  since people will likely be tempted to say anything that responds to external inputs  reacts  to them  But looking at the spirit of the thing  a program that polls an event queue at a fixed interval and dispatches any events found to functions  or threads  is less reactive  because it only attends to user input at a fixed interval   Again  it s the spirit of the thing here  one can imagine putting a polling implementation with a fast polling interval into a system at a very low level and program in a reactive fashion on top of it

User · Answer

An easy way of reaching a first intuition about what it s like is to imagine your program is a spreadsheet and all of your variables are cells  If any of the cells in a spreadsheet change  any cells that refer to that cell change as well  It s just the same with FRP  Now imagine that some of the cells change on their own  or rather  are taken from the outside world   in a GUI situation  the position of the mouse would be a good example   That necessarily misses out rather a lot  The metaphor breaks down pretty fast when you actually use a FRP system  For one  there are usually attempts to model discrete events as well  e g  the mouse being clicked   I m only putting this here to give you an idea what it s like

User · Answer

Dude  this is a freaking brilliant idea  Why didn t I find out about this back in 1998  Anyway  here s my interpretation of the Fran tutorial  Suggestions are most welcome  I am thinking about starting a game engine based on this   import pygame from pygame surface import Surface from pygame sprite import Sprite  Group from pygame locals import   from time import time as epoch delta from math import sin  pi from copy import copy  pygame init   screen   pygame display set mode  600 400   pygame display set caption  Functional Reactive System Demo    class Time      def   float   self           return epoch delta   time   Time    class Function      def   init   self  var  func  phase   0   scale   1   offset   0            self var   var         self func   func         self phase   phase         self scale   scale         self offset   offset     def copy self           return copy self      def   float   self           return self func float self var    float self phase     float self scale    float self offset      def   int   self           return int float self       def   add   self  n           result   self copy           result offset    n         return result     def   mul   self  n           result   self copy           result scale    n         return result     def   inv   self           result   self copy           result scale    -1          return result     def   abs   self           return Function self  abs   def FuncTime func  phase   0   scale   1   offset   0        global time     return Function time  func  phase  scale  offset   def SinTime phase   0   scale   1   offset   0        return FuncTime sin  phase  scale  offset  sin time   SinTime    def CosTime phase   0   scale   1   offset   0        phase    pi   2      return SinTime phase  scale  offset  cos time   CosTime    class Circle      def   init   self  x  y  radius           self x   x         self y   y         self radius   radius      property     def size self           return  self radius   2    2 circle   Circle          x   cos time   200   250          y   abs sin time    200   50          radius   50   class CircleView Sprite       def   init   self  model  color    255  0  0            Sprite   init   self          self color   color         self model   model         self image   Surface  model radius   2    2  convert alpha           self rect   self image get rect           pygame draw ellipse self image  self color  self rect      def update self           self rect      int self model x   int self model y   self model radius   2  self model radius   2 circle view   CircleView circle   sprites   Group circle view  running   True while running      for event in pygame event get            if event type    QUIT              running   False         if event type    KEYDOWN and event key    K ESCAPE              running   False     screen fill  0  0  0       sprites update       sprites draw screen      pygame display flip   pygame quit     In short  If every component can be treated like a number  the whole system can be treated like a math equation  right

User · Answer

The paper Simply efficient functional reactivity by Conal Elliott  direct PDF  233 nbsp KB  is a fairly good introduction  The corresponding library also works   The paper is now superceded by another paper  Push-pull functional reactive programming  direct PDF  286 nbsp KB

User · Answer

Check out Rx  Reactive Extensions for  NET  They point out that with IEnumerable you are basically  pulling  from a stream  Linq queries over IQueryable IEnumerable are set operations that  suck  the results out of a set  But with the same operators over IObservable you can write Linq queries that  react    For example  you could write a Linq query like  from m in MyObservableSetOfMouseMovements where m X lt 100 and m Y lt 100 select new Point m X m Y     and with the Rx extensions  that s it  You have UI code that reacts to the incoming stream of mouse movements and draws whenever you re in the 100 100 box

User · Answer

In pure functional programming  there are no side-effects  For many types of software  for example  anything with user interaction  side-effects are necessary at some level   One way to get side-effect like behavior while still retaining a functional style is to use functional reactive programming  This is the combination of functional programming  and reactive programming   The Wikipedia article you linked to is about the latter    The basic idea behind reactive programming is that there are certain datatypes that represent a value  over time   Computations that involve these changing-over-time values will themselves have values that change over time   For example  you could represent the mouse coordinates as a pair of integer-over-time values  Let s say we had something like  this is pseudo-code    x    lt mouse-x gt   y    lt mouse-y gt     At any moment in time  x and y would have the coordinates of the mouse  Unlike non-reactive programming  we only need to make this assignment once  and the x and y variables will stay  up to date  automatically  This is why reactive programming and functional programming work so well together  reactive programming removes the need to mutate variables while still letting you do a lot of what you could accomplish with variable mutations   If we then do some computations based on this the resulting values will also be values that change over time  For example   minX   x - 16  minY   y - 16  maxX   x   16  maxY   y   16    In this example  minX will always be 16 less than the x coordinate of the mouse pointer  With reactive-aware libraries you could then say something like   rectangle minX  minY  maxX  maxY    And a 32x32 box will be drawn around the mouse pointer and will track it wherever it moves   Here is a pretty good paper on functional reactive programming

[functional-programming] What is (functional) reactive programming?

Examples related to functional-programming

Examples related to terminology

Examples related to reactive-programming

Examples related to frp