Are you an EPFL student looking for a semester project?
Work with us on data science and visualisation projects, and deploy your project as an app on top of GraphSearch.
Concept
Functional reactive programming
Summary
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.
The original formulation of functional reactive programming can be found in the ICFP 97 paper Functional Reactive Animation by Conal Elliott and Paul Hudak.
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.
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. The key properties of this formulation are:
Modeling values that vary over continuous time, called "behaviors" and later "signals".
Modeling "events" 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 free languages is typically in terms of continuous functions, and typically over time. This formulation is also referred to as denotative continuous time programming (DCTP).
Formulations such as Event-Driven FRP and versions of Elm prior to 0.17 require that updates are discrete and event-driven. 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.
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.
It has been pointed out that the ordinary FRP model, from inputs to outputs, is poorly suited to interactive programs.
About this result
This page is automatically generated and may contain information that is not correct, complete, up-to-date, or relevant to your search query. The same applies to every other page on this website. Please make sure to verify the information with EPFL's official sources.