Personal tools

Functional Reactive Programming

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
m (Publications and talks: case correction)
(Libraries: libraries sorted alphabetically)
 
(14 intermediate revisions by 7 users not shown)
Line 1: Line 1:
 
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.
 
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 [http://conal.net/papers/icfp97/ 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:
 +
 +
<haskell>
 +
newtype Behavior a =
 +
    Behavior {
 +
      at :: Time -> a
 +
    }
 +
 +
myName :: Behavior Text
 +
 +
myName `at` yesterday
 +
</haskell>
 +
 +
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:
 +
 +
<haskell>
 +
myEditWidget :: Behavior Text
 +
</haskell>
 +
 +
In most frameworks there is an applicative interface for behaviors, such that you can combine them easily:
 +
 +
<haskell>
 +
liftA2 (<>) myEdit1 myEdit2
 +
</haskell>
 +
 +
The result is a time-varying value that represents the concatenation of <hask>myEdit1</hask> and <hask>myEdit2</hask>.  This could be the value of a third widget, a label, to display the concatenation.  The following is a hypothetical example:
 +
 +
<haskell>
 +
do edit1 <- editWidget
 +
  edit2 <- editWidget
 +
  label <- label (liftA2 (<>) edit1 edit2)
 +
  {- ... -}
 +
</haskell>
 +
 +
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 ===
 +
 +
''To do''
  
 
== Libraries ==
 
== Libraries ==
* [http://hackage.haskell.org/package/sodium Sodium]
 
* [[Grapefruit]]
 
* [[Reactive]]
 
 
* [[DataDriven]]
 
* [[DataDriven]]
* [[Yampa]]
 
* [[WxFruit|wxFruit]]
 
 
* [http://hackage.haskell.org/package/elerea Elerea]
 
* [http://hackage.haskell.org/package/elerea Elerea]
* [[Reactive-banana|reactive-banana]]
 
* [[Netwire]]
 
 
* [http://conal.net/fran/ Fran] (discontinued)
 
* [http://conal.net/fran/ Fran] (discontinued)
 
+
* [[Grapefruit]]
* [http://hackage.haskell.org/packages/archive/pkg-list.html#cat:frp Hackage packages in the category FRP]
+
* [[Netwire]]
 +
* [[Reactive]]
 +
* [[Reactive-banana|reactive-banana]]
 +
* [http://hackage.haskell.org/package/reflex Reflex]
 +
* [http://hackage.haskell.org/package/sodium Sodium]
 +
* [[WxFruit|wxFruit]]
 +
* [[Yampa]]
 +
* [http://hackage.haskell.org/packages/archive/pkg-list.html#cat:FRP Hackage packages in the category FRP]
 +
A simple, practical comparison between FRP libraries is done by [https://github.com/gelisam/frp-zoo frp-zoo]
  
 
== Publications and talks ==
 
== Publications and talks ==
 +
 +
* [https://www.youtube.com/watch?v=zgNRM8tZguY ICFP 2014: Settable and Non-Interfering Signal Functions for FRP - Daniel Winograd-Cort] (video)
 
* [http://www.cs.rit.edu/~eca7215/frp-independent-study/Survey.pdf A Survey of Functional Reactive Programming]
 
* [http://www.cs.rit.edu/~eca7215/frp-independent-study/Survey.pdf A Survey of Functional Reactive Programming]
 
* [http://conal.net/papers/frp.html Conal Elliott’s FRP-related publications]
 
* [http://conal.net/papers/frp.html Conal Elliott’s FRP-related publications]
 
* [https://grapefruit-project.org/publications-and-talks Grapefruit-related publications and talks]
 
* [https://grapefruit-project.org/publications-and-talks Grapefruit-related publications and talks]
 
* [http://haskell.cs.yale.edu/?page_id=65#FunctionalReactiveProgramming The Yale Haskell Group’s FRP-related publications]
 
* [http://haskell.cs.yale.edu/?page_id=65#FunctionalReactiveProgramming The Yale Haskell Group’s FRP-related publications]
 +
 +
== Books ==
 +
* Blackheath, Stephen; Jones, Antony. [http://www.manning.com/blackheath Functional Reactive Programming]. Manning Publications (2015). p.245. ISBN 978-1-6334-3010-5
  
 
== Blog posts ==
 
== Blog posts ==
 +
 +
* [https://github.com/gelisam/frp-zoo frp-zoo]; comparing many FRP implementations by reimplementing the same toy app in each.
 +
* [http://blog.reactiveprogramming.org/ Functional Reactive Programming, a better way to build interactive applications] (about the Sodium FRP Library currently for C#, C++, Haskell and Java and more to come)
 
* [http://apfelmus.nfshost.com/blog.html#functional-reactive-programming-frp FRP-related posts on Heinrich Apfelmus’ blog]
 
* [http://apfelmus.nfshost.com/blog.html#functional-reactive-programming-frp FRP-related posts on Heinrich Apfelmus’ blog]
 
* [http://conal.net/blog/tag/frp FRP-related posts on Conal Elliott’s blog]
 
* [http://conal.net/blog/tag/frp FRP-related posts on Conal Elliott’s blog]
Line 27: Line 85:
 
* [http://lukepalmer.wordpress.com/2008/11/28/relative-time-frp/ Relative time FRP] by Luke Palmer
 
* [http://lukepalmer.wordpress.com/2008/11/28/relative-time-frp/ Relative time FRP] by Luke Palmer
 
* [http://blog.edwardamsden.com/2011/03/demonstrating-time-leak-in-arrowized.html Demonstrating a Time Leak in Arrowized FRP] by Edward Amsden
 
* [http://blog.edwardamsden.com/2011/03/demonstrating-time-leak-in-arrowized.html Demonstrating a Time Leak in Arrowized FRP] by Edward Amsden
 +
* [https://www.reddit.com/r/haskell/comments/3fr5ij/frp_systems_discussion/ FRP Systems discussion] on reddit
  
 
== People ==
 
== People ==
Line 38: Line 97:
 
* [https://wolfgang.jeltsch.info/ Wolfgang Jeltsch]
 
* [https://wolfgang.jeltsch.info/ Wolfgang Jeltsch]
 
* [http://www.cs.nott.ac.uk/~nhn/ Henrik Nilsson]
 
* [http://www.cs.nott.ac.uk/~nhn/ Henrik Nilsson]
 +
* [http://github.com/ivanperez-keera Ivan Perez]
 
* [http://mcis.western.edu/~jpeterson/ John Peterson]
 
* [http://mcis.western.edu/~jpeterson/ John Peterson]
 +
* Ertugrul Söylemez
  
 
[[Category:FRP|*]]
 
[[Category:FRP|*]]

Latest revision as of 14:45, 9 July 2016

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.


Contents

[edit] 1 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.

[edit] 1.1 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
    }
 
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.

[edit] 1.2 Events

To do

[edit] 2 Libraries

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

[edit] 3 Publications and talks

[edit] 4 Books

[edit] 5 Blog posts

[edit] 6 People