Functional reactive programming (FRP) is a programming paradigm for reactive programming (asynchronous dataflow programming) using the building blocks of functional programming (e.g., map, reduce, filter). FRP has been used for programming graphical user interfaces (GUIs), robotics, games, and music, aiming to simplify these problems by explicitly modeling time.[citation needed]

Formulations of FRP

The original formulation of functional reactive programming can be found in the ICFP 97 paper Functional Reactive Animation by Conal Elliott and Paul Hudak.[1]

FRP has taken many forms since its introduction in 1997. One axis of diversity is discrete vs. continuous semantics. Another axis is how FRP systems can be changed dynamically.[2]


The earliest formulation of FRP used continuous semantics, aiming to abstract over many operational details that are not important to the meaning of a program.[3] The key properties of this formulation are:

This semantic model of FRP in side-effect free languages is typically in terms of continuous functions, and typically over time.[4] This formulation is also referred to as denotative continuous time programming (DCTP).[5]


Formulations such as Event-Driven FRP and versions of Elm prior to 0.17 require that updates are discrete and event-driven.[6] These formulations have pushed for practical FRP, focusing on semantics that have a simple API that can be implemented efficiently in a setting such as robotics or in a web-browser.[7]

In these formulations, it is common that the ideas of behaviors and events are combined into signals that always have a current value, but change discretely.[8]

Interactive FRP

It has been pointed out that the ordinary FRP model, from inputs to outputs, is poorly suited to interactive programs.[9] Lacking the ability to "run" programs within a mapping from inputs to outputs may mean one of the following solutions must be used:

 planNow :: Event (IO a) -> IO (Event a)

Implementation issues

There are two types of FRP systems, push-based and pull-based. Push-based systems take events and push them through a signal network to achieve a result. Pull-based systems wait until the result is demanded, and work backwards through the network to retrieve the value demanded.

Some FRP systems such as Yampa use sampling, where samples are pulled by the signal network. This approach has a drawback: the network must wait up to the duration of one computation step to learn of changes to the input. Sampling is an example of pull-based FRP.

The Reactive and Etage libraries on Hackage introduced an approach called push-pull FRP. In it, only when the next event on a purely defined stream (such as a list of fixed events with times) is demanded, that event is constructed. These purely defined streams act like lazy lists in Haskell. That is the pull-based half. The push-based half is used when events external to the system are brought in. The external events are pushed to consumers, so that they can find out about an event the instant it is issued.


Implementations exist for many programming languages, including:

ReactiveX, popularized by its JavaScript implementation rxjs, is functional and reactive but differs from functional reactive programming.[18]

See also


  1. ^ Elliott, Conal; Hudak, Paul. "Functional Reactive Animation". Functional Reactive Animation. ICFP ’97. Retrieved 14 July 2018.
  2. ^ Nilsson, Henrik; Courtney, Antony; Peterson, John (Feb 2011) [2002], "Functional Reactive Programming, Continued", Haskell Workshop (PDF)
  3. ^ Elliott, Conal; Hudak, Paul (1997), "Functional Reactive Animation", ICFP
  4. ^ Courtney, Antony; Elliott, Conal (Feb 2011) [2001], "Genuinely Functional User Interfaces", Haskell Workshop, Yale
  5. ^ Elliot, Conal (2014), "Denotational Design" (PDF), LambdaJam, retrieved 5 May 2023
  6. ^ Taha, Walid; Wan, Zhanyong; Hudak, Paul (2002), "Event-Driven FRP", PADL (PDF), Yale, archived from the original (PDF) on 2013-09-28, retrieved 2013-09-23
  7. ^ Czaplicki, Evan; Chong, Stephen (2013), "Asynchronous Functional Reactive Programming for GUIs", PLDI, Harvard
  8. ^ Wan, Zhanyong; Taha, Walid; Hudak, Paul (Feb 2011), "Real-Time FRP", ICFP (PDF), archived from the original (PDF) on 2013-09-28, retrieved 2013-09-23
  9. ^ Elliott, Conal (December 9, 2008). "Why classic FRP does not fit interactive behavior". Archived from the original on 2022-10-12.
  10. ^ Borning, Alan. "I/O in Purely Functional Languages" (PDF). Archived (PDF) from the original on 2022-04-28.
  11. ^ Carlsson, Magnus; Hallgren, Thomas (1998). "Fudgets – Purely Functional Processes with applications to Graphical User Interfaces" (PDF). Archived (PDF) from the original on 2022-10-15.
  12. ^ Perez, Ivan; Barenz, Manuel; Nilsson, Henrik (July 2016), "Functional Reactive Programming, Refactored", Haskell Symposium (PDF)
  13. ^ Atze van der Ploeg; Claessen, Koen. "Practical Principled FRP" (PDF). Archived from the original (PDF) on 2015-07-01. Retrieved 2015-07-24.
  14. ^ Czaplicki, Evan (Apr 2012), Elm: Concurrent FRP for Functional GUIs (PDF) (thesis), Harvard, archived from the original (PDF) on 2016-06-04, retrieved 2015-02-17((citation)): CS1 maint: location missing publisher (link)
  15. ^ Czaplicki, Evan. "A Farewell to FRP". elm. Retrieved 14 July 2018.
  16. ^ Van den Vonder, Sam; Renaux, Thierry; Oeyen, Bjarno; De Koster, Joeri; De Meuter, Wolfgang (2020), "Tackling the Awkward Squad for Reactive Programming: The Actor-Reactor Model", Leibniz International Proceedings in Informatics (LIPIcs), vol. 166, pp. 19:1–19:29, doi:10.4230/LIPIcs.ECOOP.2020.19, ISBN 9783959771542, S2CID 260445152
  17. ^ Van den Vonder, Sam; Renaux, Thierry; De Meuter, Wolfgang (2022), "Topology-Level Reactivity in Distributed Reactive Programs: Reactive Acquaintance Management using Flocks", The Art, Science, and Engineering of Programming, vol. 6, pp. 14:1–14:36, arXiv:2202.09228, doi:10.22152/, S2CID 246979565
  18. ^ "ReactiveX". Retrieved July 3, 2022.