imported>2ndjpeg: /* Implementations */ Added reference to Sodium

2024-10-05T21:31:45Z

Implementations: Added reference to Sodium

New page

{{Short description|Programming paradigm}}
{{Distinguish|text=factory reset protection (FRP), a feature in some [[Android (operating system)|Android]] devices}}
'''Functional reactive programming''' ('''FRP''') is a [[programming paradigm]] for [[reactive programming]] ([[asynchronous programming|asynchronous]] [[dataflow programming]]) using the building blocks of [[functional programming]] (e.g., [[Map (higher-order function)|map]], [[Fold (higher-order function)|reduce]], [[Filter (higher-order function)|filter]]). FRP has been used for programming [[graphical user interface]]s (GUIs), [[robotics]], games, and music, aiming to simplify these problems by explicitly modeling time.{{Citation needed|date=March 2016}}

== 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]].<ref>{{cite web |last1=Elliott |first1=Conal |last2=Hudak |first2=Paul |title=Functional Reactive Animation |url=http://conal.net/papers/icfp97/ |website=Functional Reactive Animation |publisher=ICFP ’97 |access-date=14 July 2018 |ref=fran}}</ref>

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.<ref>{{Citation |first1=Henrik |last1=Nilsson |first2=Antony |last2=Courtney |first3=John |last3=Peterson |url=https://www.antonycourtney.com/pubs/frpcont.pdf |contribution=Functional Reactive Programming, Continued |title=Haskell Workshop |orig-year=2002 |date=Feb 2011 |number=2}}</ref>

=== Continuous ===
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.<ref>{{Citation |first1=Conal |last1=Elliott |first2=Paul |last2=Hudak |contribution-url=http://conal.net/papers/icfp97/ |contribution=Functional Reactive Animation |title=ICFP |year=1997}}</ref> The key properties of this formulation are:
* Modeling values that vary over continuous time, called "behaviors" and later "signals".
* Modeling "[[event (computing)|event]]s" which have occurrences at discrete points in time.
* The system can be changed in response to events, generally termed "switching."
* The separation of evaluation details such as sampling rate from the reactive model.

This semantic model of FRP in [[Side effect (computer science)|side-effect]] free languages is typically in terms of continuous functions, and typically over time.<ref>{{Citation |first1=Antony |last1=Courtney |first2=Conal |last2=Elliott |contribution-url=https://www.antonycourtney.com/pubs/genuinely-functional-guis.ps.gz |date=Feb 2011 |publisher=Yale |contribution=Genuinely Functional User Interfaces |orig-year=2001 |title=Haskell Workshop}}</ref> This formulation is also referred to as denotative continuous time programming (DCTP).<ref>{{Citation |first1=Conal |last1=Elliot |contribution-url=http://conal.net/talks/denotational-design-lambdajam-2014.pdf |contribution=Denotational Design |title=LambdaJam |year=2014 |access-date=5 May 2023}}</ref>

=== Discrete ===
Formulations such as Event-Driven FRP and versions of [[Elm (programming language)|Elm]] prior to 0.17 require that updates are discrete and event-driven.<ref>{{Citation |first1=Walid |last1=Taha |first2=Zhanyong |last2=Wan |first3=Paul |last3=Hudak |url=http://www.cs.yale.edu/homes/zwan/papers/mcu/efrp.pdf |contribution=Event-Driven FRP |title=PADL |year=2002 |publisher=Yale |access-date=2013-09-23 |archive-url=https://web.archive.org/web/20130928163653/http://www.cs.yale.edu/homes/zwan/papers/mcu/efrp.pdf |archive-date=2013-09-28 |url-status=dead }}</ref> 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.<ref>{{Citation |first1=Evan |last1=Czaplicki |first2=Stephen |last2=Chong |publisher=Harvard |contribution-url=http://people.seas.harvard.edu/~chong/abstracts/CzaplickiC13.html |contribution=Asynchronous Functional Reactive Programming for GUIs |title=PLDI |year=2013}}</ref>

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.<ref>{{Citation |date=Feb 2011 |first1=Zhanyong |last1=Wan |first2=Walid |last2=Taha |first3=Paul |last3=Hudak |url=http://haskell.cs.yale.edu/wp-content/uploads/2011/02/rt-frp.pdf |contribution=Real-Time FRP |title=ICFP |number=1 |access-date=2013-09-23 |archive-url=https://web.archive.org/web/20130928163734/http://haskell.cs.yale.edu/wp-content/uploads/2011/02/rt-frp.pdf |archive-date=2013-09-28 |url-status=dead }}</ref>

==Interactive FRP==
It has been pointed out that the ordinary FRP model, from inputs to outputs, is poorly suited to interactive programs.<ref>{{Cite web |url=http://conal.net/blog/posts/why-classic-frp-does-not-fit-interactive-behavior |title=Why classic FRP does not fit interactive behavior |last=Elliott |first=Conal |date=December 9, 2008 |archive-url=https://web.archive.org/web/20221012020700/http://conal.net/blog/posts/why-classic-frp-does-not-fit-interactive-behavior |archive-date=2022-10-12 |url-status=live}}</ref> Lacking the ability to "run" programs within a mapping from inputs to outputs may mean one of the following solutions must be used:
*Create a data structure of actions which appear as the outputs. The actions must be run by an external interpreter or environment. This inherits all of the difficulties of the original stream [[input/output]] (I/O) system of [[Haskell]].<ref>{{cite web |url=https://courses.cs.washington.edu/courses/cse505/01au/functional/functional-io.pdf |title=I/O in Purely Functional Languages |first=Alan |last=Borning |archive-url=https://web.archive.org/web/20220428171557/https://courses.cs.washington.edu/courses/cse505/01au/functional/functional-io.pdf |archive-date=2022-04-28 |url-status=live}}</ref>
*Use Arrowized FRP and embed arrows which are capable of performing actions. The actions may also have identities, which allows them to maintain separate mutable stores for example. This is the approach taken by the Fudgets library<ref>{{Cite web|url=https://cth.altocumulus.org/~hallgren/Thesis/fudgets_thesis_color.pdf|title=Fudgets – Purely Functional Processes with applications to Graphical User Interfaces|first1=Magnus|last1=Carlsson|first2=Thomas|last2=Hallgren|year=1998|archive-url=https://web.archive.org/web/20221015141447/https://cth.altocumulus.org/~hallgren/Thesis/fudgets_thesis_color.pdf|archive-date=2022-10-15|url-status=live}}</ref> and, more generally, Monadic Stream Functions.<ref>{{Citation |date=July 2016 |first1=Ivan |last1=Perez |first2=Manuel |last2=Barenz |first3=Henrik |last3=Nilsson |url=http://www.cs.nott.ac.uk/~psxip1/papers/2016-HaskellSymposium-Perez-Barenz-Nilsson-FRPRefactored-short.pdf |contribution=Functional Reactive Programming, Refactored |title=Haskell Symposium}}</ref>
*The novel approach is to allow actions to be run now (in the IO monad) but defer the receipt of their results until later.<ref>{{Cite web |url=http://www.cse.chalmers.se/~atze/papers/prprfrp.pdf |title=Practical Principled FRP |author1=Atze van der Ploeg |first2=Koen |last2=Claessen |access-date=2015-07-24 |archive-url=https://web.archive.org/web/20150701030428/http://www.cse.chalmers.se/~atze/papers/prprfrp.pdf |archive-date=2015-07-01 |url-status=dead }}</ref> This makes use of an interaction between the Event and IO monads, and is compatible with a more expression-oriented FRP:
{{sxhl|2=elm|
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 ==
Implementations exist for many [[programming language]]s, including:
* Yampa is an arrowized, efficient, pure [[Haskell]] implementation with SDL, SDL2, OpenGL and HTML DOM support.
* The language [[Elm (programming language)|Elm]] used to support FRP<ref>{{Citation |first=Evan |last=Czaplicki |url=https://www.seas.harvard.edu/sites/default/files/files/archived/Czaplicki.pdf |title=Elm: Concurrent FRP for Functional GUIs |date=Apr 2012 |place=Harvard |type=thesis |access-date=2015-02-17 |archive-url=https://web.archive.org/web/20160604000246/http://www.seas.harvard.edu/sites/default/files/files/archived/Czaplicki.pdf |archive-date=2016-06-04 |url-status=dead }}</ref> but has since replaced it with a different pattern.<ref>{{cite web |last1=Czaplicki |first1=Evan |title=A Farewell to FRP |url=http://elm-lang.org/blog/farewell-to-frp |website=elm |access-date=14 July 2018 |ref=farewell-to-frp}}</ref>
* reflex is an efficient push–pull FRP implementation in Haskell with hosts for [[web browser]] – [[Document Object Model]] (DOM), [[Simple DirectMedia Layer]] (SDL), and Gloss.
* reactive-banana is a target-agnostic push FRP implementation in Haskell.
* netwire and varying are arrowized, pull FRP implementations in Haskell.
* [[Flapjax]] is a behavior–event FRP implementation in [[JavaScript]].
* React is an [[OCaml]] module for functional reactive programming.
* Sodium is a push FRP implementation independent of a specific [[user interface]] (UI) framework for several languages, such as [[Java (programming language)|Java]], [[TypeScript]], and [[C Sharp (programming language)|C#]].<ref>{{cite web |url=https://github.com/SodiumFRP/sodium |title=Sodium FRP Library on Github |access-date=October 5, 2024}}</ref>
* Dunai is a fast implementation in Haskell using [[Monadic Stream Functions]] that supports Classic and Arrowized FRP.
* ObservableComputations, a cross-platform [[.NET]] implementation.
* Stella is an [[actor model]]-based reactive language that demonstrates a model of "actors" and "reactors" which aims to avoid the issues of combining imperative code with reactive code (by separating them in actors and reactors).<ref name="stella">{{Citation |url=https://drops.dagstuhl.de/opus/volltexte/2020/13176/ |first1=Sam |last1=Van den Vonder |first2=Thierry |last2=Renaux |first3=Bjarno |last3=Oeyen |first4=Joeri |last4=De Koster |first5=Wolfgang |last5=De Meuter |contribution=Tackling the Awkward Squad for Reactive Programming: The Actor-Reactor Model |title=Leibniz International Proceedings in Informatics (LIPIcs) |volume=166 |year=2020 |pages=19:1–19:29 |doi=10.4230/LIPIcs.ECOOP.2020.19 |doi-access=free |isbn=9783959771542 |s2cid=260445152}}</ref> Actors are suitable for use in distributed reactive systems.<ref name="stella2">{{Citation |url=https://programming-journal.org/2022/6/14/ |first1=Sam |last1=Van den Vonder |first2=Thierry |last2=Renaux |first3=Wolfgang |last3=De Meuter |contribution=Topology-Level Reactivity in Distributed Reactive Programs: Reactive Acquaintance Management using Flocks |title=The Art, Science, and Engineering of Programming |volume=6 |year=2022 |issue=3 |pages=14:1–14:36 |doi=10.22152/programming-journal.org/2022/6/14 |s2cid=246979565|doi-access=free |arxiv=2202.09228 }}</ref>
*[[TidalCycles]] is a pure FRP domain specific language for musical pattern, embedded in the [[Haskell]] language.

[[ReactiveX]], popularized by its [[JavaScript]] implementation rxjs, is functional and reactive but differs from functional reactive programming.<ref>{{cite web |url=https://reactivex.io/intro.html |title=ReactiveX |website=ReactiveX.io |access-date=July 3, 2022}}</ref>

== See also ==
* [[Incremental computing]]
* [[Stream processing]]

== References ==
{{Reflist}}

{{Programming paradigms navbox}}

{{DEFAULTSORT:Functional reactive programming}}
[[Category:Functional programming]]
[[Category:Evaluation strategy]]

Functional reactive programming - Revision history

imported>2ndjpeg: /* Implementations */ Added reference to Sodium