Active Expressions: Basic Building Blocks for Reactive Programming

📝 Abstract

Modern software development without reactive programming is hard to imagine. Reactive programming favors a wide class of contemporary software systems that respond to user input, network messages, and other events. While reactive programming is an active field of research, the implementation of reactive concepts remains challenging. In particular, change detection represents a hard but inevitable necessity when implementing reactive concepts. Typically, change detection mechanisms are not intended for reuse but are tightly coupled to the particular change resolution mechanism. As a result, developers often have to re-implement similar abstractions. A reusable primitive for change detection is still missing. To find a suitable primitive, we identify commonalities in existing reactive concepts. We discover a class of reactive concepts, state-based reactive concepts. All state-based reactive concepts share a common change detection mechanism: they detect changes in the evaluation result of an expression. On the basis of the identified common change detection mechanism, we propose active expressions as a reusable primitive. By abstracting the tedious implementation details of change detection, active expressions can ease the implementation of reactive programming concepts. We evaluate the design of active expressions by re-implementing a number of existing state-based reactive concepts using them. The resulting implementations highlight the expressiveness of active expressions. Active expressions enable the separation of essential from non-essential parts when reasoning about reactive programming concepts. By using active expressions as a primitive for change detection, developers of reactive language constructs and runtime support can now focus on the design of how application programmers should be able to react to change. Ultimately, we would like active expressions to encourage experiments with novel reactive programming concepts and with that to yield a wider variety of them to explore.

💡 Analysis

Modern software development without reactive programming is hard to imagine. Reactive programming favors a wide class of contemporary software systems that respond to user input, network messages, and other events. While reactive programming is an active field of research, the implementation of reactive concepts remains challenging. In particular, change detection represents a hard but inevitable necessity when implementing reactive concepts. Typically, change detection mechanisms are not intended for reuse but are tightly coupled to the particular change resolution mechanism. As a result, developers often have to re-implement similar abstractions. A reusable primitive for change detection is still missing. To find a suitable primitive, we identify commonalities in existing reactive concepts. We discover a class of reactive concepts, state-based reactive concepts. All state-based reactive concepts share a common change detection mechanism: they detect changes in the evaluation result of an expression. On the basis of the identified common change detection mechanism, we propose active expressions as a reusable primitive. By abstracting the tedious implementation details of change detection, active expressions can ease the implementation of reactive programming concepts. We evaluate the design of active expressions by re-implementing a number of existing state-based reactive concepts using them. The resulting implementations highlight the expressiveness of active expressions. Active expressions enable the separation of essential from non-essential parts when reasoning about reactive programming concepts. By using active expressions as a primitive for change detection, developers of reactive language constructs and runtime support can now focus on the design of how application programmers should be able to react to change. Ultimately, we would like active expressions to encourage experiments with novel reactive programming concepts and with that to yield a wider variety of them to explore.

📄 Content

Active Expressions Basic Building Blocks for Reactive Programming Stefan Ramsona and Robert Hirschfelda a Hasso Plattner Institute, University of Potsdam, Germany Abstract Modern software development without reactive programming is hard to imagine. Reactive pro- gramming favors a wide class of contemporary software systems that respond to user input, network mes- sages, and other events. While reactive programming is an active field of research, the implementation of reactive concepts remains challenging. In particular, change detection represents a hard but inevitable necessity when implementing reactive concepts. Typically, change detection mechanisms are not intended for reuse but are tightly coupled to the particular change resolution mechanism. As a result, developers often have to re-implement similar abstractions. A reusable primitive for change detection is still missing. To find a suitable primitive, we identify commonalities in existing reactive concepts. We discover a class of reactive concepts, state-based reactive concepts. All state-based reactive concepts share a common change detection mechanism: they detect changes in the evaluation result of an expression. On the basis of the identified common change detection mechanism, we propose active expressions as a reusable primitive. By abstracting the tedious implementation details of change detection, active expressions can ease the implementation of reactive programming concepts. We evaluate the design of active expressions by re-implementing a number of existing state-based reactive concepts using them. The resulting implementations highlight the expressiveness of active expressions. Active expressions enable the separation of essential from non-essential parts when reasoning about re- active programming concepts. By using active expressions as a primitive for change detection, developers of reactive language constructs and runtime support can now focus on the design of how application program- mers should be able to react to change. Ultimately, we would like active expressions to encourage experiments with novel reactive programming concepts and with that to yield a wider variety of them to explore. ACM CCS 2012 Software and its engineering →Patterns; Control structures; Very high level languages; Multiparadigm languages; Keywords reactive programming, object-oriented programming, change detection The Art, Science, and Engineering of Programming Submitted December 1, 2016 Published April 1, 2017 doi 10.22152/programming-journal.org/2017/1/12 © Stefan Ramson and Robert Hirschfeld This work is licensed under a “CC BY 4.0” license. In The Art, Science, and Engineering of Programming, vol. 1, no. 2, 2017, article 12; 49 pages. Active Expressions 1 Introduction It is hard to imagine modern software development without reactive programming. Many contemporary software systems are inherently reactive: a Web application needs to react to messages from the server, editing a cell in a spreadsheet might change other cells that depend on the edited cell’s value, and embedded software reacts to signals of the hardware. Even though reactive programming is widely-used, plain imperative programming is still the norm due to the intrinsic nature of the underlying machine model. However, empirical studies hint at potential advantages of reactive programming over imperative approaches. Studies of non-programmer’s solutions reveal that reactive programming reflects natural reasoning about problems [27]. Fur- ther studies examine program comprehension in graphical animations and interactive applications. The studies reveal that reactive programming improves the correctness of comprehending reactive behavior compared to traditional object-oriented program- ming (oop) solutions [28]. For those reasons, reactive programming concepts often seem a desirable abstraction over imperative environments. Although there are various incarnations of the reactive programming paradigm, their implementations usually consist of two parts: detection of change and reaction to change. The reaction part defines how to propagate detected changes through the system. The reaction is usually seen as the heart of a reactive concept. Most design decisions regard this part, as it is the part of actual, visible functionality. The detection part is responsible for detecting changes and events. In contrast to reaction, the detection remains hidden to the application programmer. Also, the detection part serves no inherent, concept-specific purpose, but instead is conceptually exchangeable. Therefore, this part is often perceived as an implementation detail. However, the detection has a major impact on practical implementations. This issue becomes especially apparent when dealing with a change detection mechanism beyond manual event-emitting, for example detecting when a constraint expression becomes unsatisfied in a scenario that respects object-oriented encapsulation [8]. Ideally, even complex change det

This content is AI-processed based on ArXiv data.