A livecoding semantics for functional reactive programming

Murphy, Tom

doi:10.1145/2975980.2975986

Cited by 7 publications

(4 citation statements)

References 5 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Typically, an RP language provides stateful operators that hide a stateful variable in their implementation. Examples include integral [9,15], pre [58], latch [54], and foldp [8,12,34]. We propose a different approach that makes mutable state an explicit part of the language model.…”

Section: Trampoline Variablesmentioning

confidence: 99%

Reactive Programming without Functions

Oeyen,

De Koster,

De Meuter

2024

Programming

View full text Add to dashboard Cite

ContextReactive programming (RP) is a declarative programming paradigm suitable for expressing the handling of events. It enables programmers to create applications that react automatically to changes over time. Whenever a time-varying signal changes -e.g. in response to values produced by event stream (e.g., sensor data, user input…) -the program state is updated automatically in tandem with that change. This makes RP well-suited for building interactive applications and reactive (soft real-time) systems. Inquiry RP Language implementations are often built on top of an existing (host) language as an Embedded Domain Specific Language (EDSL). This results in application code in which reactive code and non-reactive code is inherently entangled. Using a mechanism known as lifting, one usually has access to the full feature set of the (non-reactive) host language in the RP program. However, lifting is also dangerous. First, host code expressed in a Turing-complete language may diverge, resulting in unresponsive programs: i.e. reactive programs that are not actually reactive. Second, the bi-directional integration of reactive and non-reactive code results in a paradigmatic mismatch that, when unchecked, leads to faulty behaviour in programs. Approach We propose a new reactive programming language, that has been meticulously designed to be reactive-only. We start with a simple (first-order) model for reactivity, based on reactors (i.e. uninstantiated descriptions of signals and their dependencies) and deployments (i.e. instances of reactors) that consist of signals. The language does not have the notion of functions, and thus unlike other RP languages there is no lifting either. We extend this simple model incrementally with additional features found in other programming languages, RP or otherwise. These features include stateful reactors (that allow for time-based accumulation), signals with dynamic dependencies by means of conditionals and polymorphic deployments, recursively-defined reactors, and (anonymous) reactors with lexical scope. Knowledge In our description of these language features, we not only describe the syntax and semantics, but also how each features compares to the problems that exist in (EDSL) RP languages. I.e. by starting from a reactive-only model, we identify which reactive features (that, in other RP languages are typically expressed in non-reactive code) affect the reactive guarantees that can be enforced by the language. Grounding We base our arguments by analysing the effect that each feature has on our language: e.g., by analysing how signals are updated, how they are created and how dependencies between signals can be affected. When applicable, we draw parallels with other languages: i.e. similarities shared with other RP languages will be highlighted and thoroughly analysed, and where relevant the same will also be done with non-reactive languages. Importance Our language shows how a purely reactive programming is able to express the same kinds of programs as in other RP languages that re...

show abstract

Section: Trampoline Variablesmentioning

confidence: 99%

Reactive Programming without Functions

Oeyen,

De Koster,

De Meuter

2024

Programming

View full text Add to dashboard Cite

show abstract

“…CFRP [43], Elm [16], Frenetic [20], Flask [28], FRPNow [45], FrTime [13], Gavial [37], Hae [50], Hokko [36], Midair [30], ReactiFi [42], REScala [38], and SFRP [10]. feedback Given a signal function (i.e., a reactive program) of type SF (𝑎, 𝑐) (𝑏, 𝑐) (where (𝑎, 𝑐) is the input type and (𝑏, 𝑐) the output type) and an initial value 𝑣, creates a new signal function of type SF 𝑎 𝑏 which contains the original signal function, connecting the output of type 𝑐 to the input of type 𝑐 with an implicit one-turn delay (i.e.…”

Section: Delaybymentioning

confidence: 99%

“…Other RP languages with support for hot-code reloading also have similar issues related to state retention: • In Midair [30], an RP language with support for hot-code reloading built on of Haskell, SFlows (i.e. signal functions from [22]) can be replaced at-runtime by the programmer.…”

Section: Hot-swapping With Trampolinesmentioning

confidence: 99%

Trampoline variables: a general method for state accumulation in reactive programming

Oeyen

Vonder

Meuter

2021

Proceedings of the 8th ACM SIGPLAN International Workshop on Reactive and Event-Based Languages and Systems

View full text Add to dashboard Cite

Reactive programming is all about relegating the management of a program's state changes to the realm of the runtime environment. Nevertheless, sometimes it is still necessary to enrich a reactive program with state variables that are explicitly updated by the programmer. In current reactive languages this is accomplished either by polluting the reactive paradigm with imperative constructs or by relying on built-in operators such as foldp.This paper introduces trampoline variables, a new general mechanism that allows reactive programs to manipulate state explicitly without resorting to imperative programming. We show that our proposal is at least as powerful as existing built-in reactive operators. We also analyse how reactive programs with trampoline variables can be composed and how they can form the basis to replace stateful constituents of a running reactive program -a.k.a. hotswapping -in a coherent way. The latter is an essential building block towards live IDEs for reactive programming languages.CCS Concepts: • Software and its engineering → Data flow languages.

show abstract

“…CCAs are an abstraction subsumed by other functional reactive programming abstractions, such as Monads, Applicative and Arrows [33,32]. There are many FRP libraries using Monads [12,14,42], Applicative [1,2,22,49], or Arrows [10,39,41,52], and since every Monad is also an Applicative and Applicative/Arrows both are universal design patterns, we can give uniform translations to all of these libraries using translations to just Applicative and Arrows. Both translations are possible due to the flexible notion of a CFM.…”

Section: Control Flow Modelmentioning

confidence: 99%

Temporal Stream Logic: Synthesis Beyond the Bools

Finkbeiner

Klein

Piskač

et al. 2019

Computer Aided Verification

View full text Add to dashboard Cite

Reactive systems that operate in environments with complex data, such as mobile apps or embedded controllers with many sensors, are difficult to synthesize. Synthesis tools usually fail for such systems because the state space resulting from the discretization of the data is too large. We introduce TSL, a new temporal logic that separates control and data. We provide a CEGAR-based synthesis approach for the construction of implementations that are guaranteed to satisfy a TSL specification for all possible instantiations of the data processing functions. TSL provides an attractive trade-off for synthesis. On the one hand, synthesis from TSL, unlike synthesis from standard temporal logics, is undecidable in general. On the other hand, however, synthesis from TSL is scalable, because it is independent of the complexity of the handled data. Among other benchmarks, we have successfully synthesized a music player Android app and a controller for an autonomous vehicle in the Open Race Car Simulator (TORCS). SynthesisLTL Circuit n FRP Translator Project Context Compiler LTL Synthesis Tool Counter Strategy Refinement unrealizable Design Pattern: Arrow | Applicative FRP EXE Function & Predicate Implementations FRP Library ✓ non-spurious spurious Sys . leaveApp () if ( MP . musicPlaying () ) Ctrl . pause () ; Sys . resumeApp () { pos = MP . trackPos () ; Ctrl . play ( Tr , pos ) ; } ALWAYS leaveApp Sys ∧ musicPlaying MP → Ctrl pause() ALWAYS resumeApp Sys → Ctrl play Tr (trackPos MP)

show abstract

A livecoding semantics for functional reactive programming

Cited by 7 publications

References 5 publications

Reactive Programming without Functions

Reactive Programming without Functions

Trampoline variables: a general method for state accumulation in reactive programming

Temporal Stream Logic: Synthesis Beyond the Bools

Contact Info

Product

Resources

About