A survey on reactive programming

Abstract

Reactive programming has recently gained popularity as a paradigm that is well-suited for developing event-driven and interactive applications. It facilitates the development of such applications by providing abstractions to express time-varying values and automatically managing dependencies between such values. A number of approaches have been recently proposed embedded in various languages such as Haskell, Scheme, JavaScript, Java, .NET, etc. This survey describes and provides a taxonomy of existing reactive programming approaches along six axes: representation of time-varying values, evaluation model, lifting operations, multidirectionality, glitch avoidance, and support for distribution. From this taxonomy, we observe that there are still open challenges in the field of reactive programming. For instance, multidirectionality is supported only by a small number of languages, which do not automatically track dependencies between time-varying values. Similarly, glitch avoidance, which is subtle in reactive programs, cannot be ensured in distributed reactive programs using the current techniques. INTRODUCTIONToday's applications are increasingly becoming highly interactive, driven by all sorts of events originating from within the applications and their outside environment. Such event-driven applications maintain continuous interaction with their environment, processing events and performing corresponding tasks such as updating the application state and displaying data [Pucella 1998]. The most interactive part of such appli- Author's addresses: Software Languages Lab, Vrije Universiteit Brussel, Pleinlaan 2, 1050 Elsene, Brussels, Belgium; email: ebainomu@vub.ac.be Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies show this notice on the first page or initial screen of a display along with the full citation. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use any component of this work in other works requires prior specific permission and/or a fee. Permissions may be requested from Publications Dept., ACM, Inc., 2 Penn Plaza, Suite 701, New York, NY 10121-0701 USA, fax +1 (212) 869-0481, or permissions@acm.org. cations is usually the GUI, which typically needs to react to and coordinate multiple events (e.g., mouse clicks, keyboard button presses, multi-touch gestures, etc.).These applications are difficult to program using conventional sequential programming approaches, because it is impossible to predict or control the order of arrival of external events and as such control jumps around event handlers as the outside environment changes unexpectedly (inverted control, i.e., the control flow of a program is driven by external events and not by an order specified by the programmer). Moreo...

Reactive Control of Autonomous Drones

“…We tackle this issue using a technique called reactive programming (RP) [8], illustrated in Sec. 6.1.…”

“…Sec. 6 describes our custom realization of reactive programming (RP) techniques [8] to tackle this problem.…”

Development of Applications for Interactive and Reproducible Research: a Case Study

“…Furthermore, the R environment offers the adoption of the Shiny framework [13], which allows for a lightweight and effective creation of interactive graphical user interfaces, and exploits reactive programming [17] to make computation of the underlying R objects efficient.…”

Stream my models: Reactive peer-to-peer distributed models@run.time

“…It aims at supporting the development of asynchronous, event-driven, and interactive applications by allowing to declaratively express programs in terms of what to do when a certain event occurs [12]. Reactive programming extends the observer pattern [13] to support continuous data streams and events while abstracting from low-level tasks like threading, synchronization, and non-blocking I/O.…”