Glossary

Haskell Base

Applicative

just links and papers

Arrow

short description okay, links and papers

Functor

just links and papers

lifting

lifting a function to a Monad, lifting a Monad down the stack, lifting a Monad to MSF

Monad

just links and papers

Monad Transformer

just links and papers

Monadic Stream Function

see Dunai, [FrpRefac16]

Monadic Streams

TODO

MSF

see Monadic Stream Function

widening

Arrow widening

Terminology

AFRP

see functional reactive programming, arrowized

Behaviour

TODO

causal

TODO

CFRP

see functional reactive programming, classic

circuit network

see signal network

DCTP

see denotative continuous time programming

denotative continuous time programming

Stackoverflow.com - Specification for a Functional Reactive Programming language (2011) by Conal Elliott: “I’m glad you’re starting by asking about a specification rather than implementation first. There are a lot of ideas floating around about what FRP is. …”

domain-specific language

TODO

dynamic structure

it’s one thing to run a fixed sized list of signals all behaving the same but another to make it change dynamically and with changing behaviours

Event

TODO

FP

see functional programming

FRP

see functional reactive programming

functional programming

TODO

functional reactive programming

Stackoverflow.com - What is (functional) reactive programming? (2009) by Conal Elliott

[FrpExt17] 3.3.2 “FRP tries to shift the direction of data-flow from message passing to data dependency. This helps reason about what things are over time, as opposed to how changes propagate.”

functional reactive programming, arrowized

TODO: links to papers

functional reactive programming, classic

TODO: links to papers

functional reactive programming, pull-based

TODO: links to papers

functional recative programming, push-based

TODO: links to papers

hybrid system

TODO

imperative programming

TODO

object-oriented programming

TODO

procedural programming

TODO

programming paradigm

Roy, Peter Van und Seif Haridi: Concepts, Techniques, and Models of Computer Programming. MIT Press, 2004.

reactive programming

TODO: links to papers

simulation, deterministic

TODO

simulation, non-deterministic

TODO

space-leak

also see time-leak

state

building state up over time, not to be confused with State monad

temporal

TODO

time, continuous

Conal Elliott - Why program with continuous time?

time, discrete

TODO

time, hybrid

TODO

time-leak

also see space-leak

Yampa

embedding

TODO

reactimating

TODO

sense

TODO

actuate

TODO

wormholes

TODO

white hole

TODO

black hole

TODO

Switch

TODO

Signal

TODO

SF

see Signal Function

Signal Function

TODO

Signal Network

TODO: image

Implementations

BearRiver

new Yampa, compare with Dunai and Yampa

Clean

FRP implementation

Dunai

compare with Yampa and BearRiver

E-FRP

eventbased, FRP implementation

Elm

[FrpRefac16] 3.3.2 Limitations of FRP and Arrowized FRP: “Some FRP and FRP-inspired implementations and languages offer mechanisms to work around this problem. Elm [83], for instance, offers handles to push specific changes onto widgets, thus helping to break cycles involving interactive visual elements.”

Esterel

[FrpRefac16] 11.1 Related Work - MSFs: “Esterel is a synchronous data-flow programming language with support for concurrency and signal inhibition. Esterel rejects programs that give multiple values to the same signal at the same sampling time. Our framework support classic FRP and, in principle, signals are defined once for all time. Signals in Esterel can be broadcasted across the whole program from any point. This form of broadcasting might be implementable with MSFs by means of a State monad. However, Esterel provides additional static guarantees, for example, that a broadcasted signal only has one value per cycle, and this could only be detectable during runtime with the approach based on MSF’s mentioned above.”

Euterpea

compare with Yampa

FRPNow!

FRP library

Lucid Synchrone

not to be confused with :hackage:lucid DSL for HTML

[FrpRefac16] 11.1 Related Work - MSFs: “Lucid Synchrone is a programming language inspired by Lustre, which extends it with high-level concepts from functional programming, a richer type language, and a more versatile and usable clock system. Types in Lucid Synchrone are polymorphic, and the type system supports type inference. This approach is closer to our MSFs, due to the richness of the language, although MSFs do not explicitly support clocks or include any kind of clock calculus. Like in the case of Lustre, the language of MSFs is bigger than that of Lucid Synchrone nodes: constructions that would be rejected by Lucid Synchrone’s compiler might be accepted by the Haskell compiler if described using MSF. This makes these languages, in principle, safer than full MSFs, unless the”

Lustre

[FrpRefac16] 11.1 Related Work - MSFs: “Lustre is a synchronous data-flow programming language that has been used in aerospace, transportation, nuclear power plants and wind turbines, among many others. Lustre programs are defined in terms of flows (streams) and nodes (causal stream functions). Lustre’s type system includes both information about the amount of history examined of each flow examined by each node, and clocking rates at which each flow is being produced. Together with Lustre’s clock calculus, this helps guarantee that all flows are well-formed (always defined). MSFs do not have any notion of clocks or clocking rate, making it, in principle, harder to capture those constraints and ensure the same kinds of guarantees. MSFs are defined and combined using a series of combinators that ensure that all values are well-typed. Nevertheless, our language is embedded in Haskell, which allows representing bottoms, so a program written using MSFs may not be guaranteed to be productive (simply because the programmer may have used non-terminating Haskell expressions).”

Netwire
FRP library

http://hub.darcs.net/ertes/netwire.

Reactive Banana

[FrpRefac16] 3.3.2 Limitations of FRP and Arrowized FRP: “Some FRP and FRP-inspired implementations and languages offer mechanisms to work around this problem… Reactive Banana offers sinks for each WX widget property, to which a signal can be attached. These mechanisms are not general solutions applicable to every reactive element, but ad hoc solutions to enable pushing changes to specific kinds of resources.”

RT-FRP

realtime, FRP implementation

Unity

Unity3D game engine

Yampa

old Yampa, compare with BearRiver and Dunai