Functional Reactive Programming: Difference between revisions

From HaskellWiki
(→‎Libraries: reflex main url)
m (Events described, added link to "Fran paper")
Line 15: Line 15:
newtype Behavior a =
newtype Behavior a =
     Behavior {
     Behavior {
       at :: Time -> a
       at :: Time -> a -- see page 3 of Fran paper.
     }
     }


Line 48: Line 48:
=== Events ===
=== Events ===


''To do''
While behaviours work well for describing properties which are continuous (e.g. the motion of an animated object), other properties are more ''discrete'' (e.g. what button on the mouse was clicked or the screen position where it happened). Events more easily accommodate information like this, by associating the data value of interest with a particular time:
 
<haskell>
newtype Event a =
    Event {
      occ :: (Time, a) -- see page 3 of Fran paper.
    }
</haskell>
 
A series of events is most easily represented as a list of <code>Event</code>-values, commonly referred to as an ''event stream'' (or simply a ''stream'').


== Libraries ==
== Libraries ==
Line 69: Line 78:
== Publications and talks ==
== Publications and talks ==


* The original paper that started it all - the "''Fran'' paper": [https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.701.930&rep=rep1&type=pdf Functional Reactive Programming] by Paul Hudak and Conal Elliott.
* [https://www.youtube.com/watch?v=zgNRM8tZguY ICFP 2014: Settable and Non-Interfering Signal Functions for FRP - Daniel Winograd-Cort] (video)
* [https://www.youtube.com/watch?v=zgNRM8tZguY ICFP 2014: Settable and Non-Interfering Signal Functions for FRP - Daniel Winograd-Cort] (video)
* [https://web.archive.org/web/20150217184805/https://www.cs.rit.edu/~eca7215/frp-independent-study/Survey.pdf A Survey of Functional Reactive Programming]
* [https://web.archive.org/web/20150217184805/https://www.cs.rit.edu/~eca7215/frp-independent-study/Survey.pdf A Survey of Functional Reactive Programming]

Revision as of 22:27, 12 November 2021

Functional Reactive Programming (FRP) integrates time flow and compositional events into functional programming. This provides an elegant way to express computation in domains such as interactive animations, robotics, computer vision, user interfaces, and simulation.


Introduction

The original formulation of Functional Reactive Programming can be found in the ICFP 97 paper Functional Reactive Animation by Conal Elliott and Paul Hudak.

Behaviors

Traditionally a widget-based user interface is created by a series of imperative actions. First an action is invoked to create an edit widget, then additional actions can be invoked to read its current content, set it to a specific value or to assign an event callback for when the content changes. This is tedious and error-prone.

A better way to represent an edit widget's content is a time-varying value, called a behavior. The basic idea is that a time-varying value can be represented as a function of time: 

newtype Behavior a =
    Behavior {
      at :: Time -> a  -- see page 3 of Fran paper.
    }

myName :: Behavior Text

myName `at` yesterday

This is only a theoretical model, because a time-varying value can represent something impure like the content of an edit widget, the current value of a database entry as well as the system clock's current time. Using this model the current content of an edit widget would be a regular first class value: 

myEditWidget :: Behavior Text

In most frameworks there is an applicative interface for behaviors, such that you can combine them easily: 

liftA2 (<>) myEdit1 myEdit2

The result is a time-varying value that represents the concatenation of myEdit1 and myEdit2. This could be the value of a third widget, a label, to display the concatenation. The following is a hypothetical example: 

do edit1 <- editWidget
   edit2 <- editWidget
   label <- label (liftA2 (<>) edit1 edit2)
   {- ... -}

Without behaviors you would have to write event callback actions for the edit widgets to update the label's content. With behaviors you can express this relationship declaratively.

Events

While behaviours work well for describing properties which are continuous (e.g. the motion of an animated object), other properties are more discrete (e.g. what button on the mouse was clicked or the screen position where it happened). Events more easily accommodate information like this, by associating the data value of interest with a particular time: 

newtype Event a =
    Event {
      occ :: (Time, a) -- see page 3 of Fran paper.
    }

A series of events is most easily represented as a list of Event-values, commonly referred to as an event stream (or simply a stream).

Libraries

A simple, practical comparison between FRP libraries is done by frp-zoo

Publications and talks

Books

Blog posts

People

Retrieved from "https://wiki.haskell.org/index.php?title=Functional_Reactive_Programming&oldid=64846"