Personal tools

Reactive

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
(trimmed way down from old-reactive and brought up to date)
(Category:Reactivity removed)
 
(17 intermediate revisions by 7 users not shown)
Line 1: Line 1:
[[Category:Events]]
 
[[Category:Reactivity]]
 
 
[[Category:FRP]]
 
[[Category:FRP]]
 
[[Category:Packages]]
 
[[Category:Packages]]
Line 6: Line 4:
 
== Abstract ==
 
== Abstract ==
   
'''Note:''' This page replaces [[old-reactive]]. The new '''reactive''' is not quite ready for easy use yet, but it's getting there.
+
'''Reactive''' is a simple foundation for [[Functional Reactive Programming|programming reactive systems functionally]]. Like [http://conal.net/Fran/ Fran]/FRP, Reactive has a notions of (reactive) behaviors and events. Some unusual features:
 
'''Reactive''' is a simple foundation for [[Functional Reactive Programming|programming reactive systems functionally]]. Like Fran/FRP, Reactive has a notions of (reactive) behaviors and events. Some unusual features:
 
 
* Much of the original interface is replaced by instances of standard type classes. In most cases, the denotational semantics of these instances is simple and inevitable, following from the principle of [http://conal.net/blog/posts/simplifying-semantics-with-type-class-morphisms/ type class morphisms].
 
* Much of the original interface is replaced by instances of standard type classes. In most cases, the denotational semantics of these instances is simple and inevitable, following from the principle of [http://conal.net/blog/posts/simplifying-semantics-with-type-class-morphisms/ type class morphisms].
 
* The original idea of reactive behaviors is composed out of two simple notions:
 
* The original idea of reactive behaviors is composed out of two simple notions:
** ''Reactive values'' are temporally discrete and reactive.
+
** ''Reactive values'' are temporally discrete and reactive. They have a purely data representation, and so cache for free.
 
** ''Time functions'' are temporally continuous and non-reactive.
 
** ''Time functions'' are temporally continuous and non-reactive.
* Reactive provides and builds on "functional futures", which are time/value pairs with several handy type class instances. Futures allow one to conveniently compute with values before they can be known, with a simple, purely functional semantics (no IO). Futures are polymorphic over both values ''and'' time, requiring only that time is ordered.
+
* Reactive provides and builds on ''functional futures'', which are time/value pairs with several handy type class instances. Futures allow one to conveniently compute with values before they can be known, with a simple, purely functional semantics (no IO). Futures are polymorphic over both values ''and'' time, requiring only that time is ordered.
* A particularly useful type of time, based on Warren Burton's "improving values", reveals partial information in the form of lower bounds and minima, before the times can be known precisely. (Semantically non-flat.)
+
* A particularly useful type of time, based on Warren Burton's ''improving values'', reveals partial information in the form of lower bounds and minima, before the times can be known precisely. (Semantically non-flat.)
* Improving values are implemented on top of a semantically simple "unambiguous choice" operator, [[unamb]]. Although unamb is built on [[GHC/Concurrency|Concurrent Haskell]] threads, the scheduler nondeterminism does not leak through (assuming the argument-compatibility precondition holds).
+
* Improving values are implemented on top of a semantically simple ''unambiguous choice'' operator, [[unamb]]. Although unamb is built on [[GHC/Concurrency|Concurrent Haskell]] threads, the scheduler nondeterminism does not leak through (assuming the argument-compatibility precondition holds).
 
* Reactive manages (I hope) to get the efficiency of data-driven computation with a (sort-of) demand-driven architecture. For that reason, Reactive is garbage-collector-friendly. ([[DataDriven#GC_favors_demand-driven_computation|GC favors demand-driven computation]].)
 
* Reactive manages (I hope) to get the efficiency of data-driven computation with a (sort-of) demand-driven architecture. For that reason, Reactive is garbage-collector-friendly. ([[DataDriven#GC_favors_demand-driven_computation|GC favors demand-driven computation]].)
* Reactive elegantly and efficiently ''caches'' values.
+
   
 
The inspiration for Reactive was Mike Sperber's [http://www-pu.informatik.uni-tuebingen.de/lula/deutsch/publications.html Lula] implementation of FRP. Mike used blocking threads, which I had never considered for FRP before a conversation with him at ICFP 2007. While playing with the idea, I realized that I could give a very elegant and efficient solution to caching.
 
The inspiration for Reactive was Mike Sperber's [http://www-pu.informatik.uni-tuebingen.de/lula/deutsch/publications.html Lula] implementation of FRP. Mike used blocking threads, which I had never considered for FRP before a conversation with him at ICFP 2007. While playing with the idea, I realized that I could give a very elegant and efficient solution to caching.
   
Besides this wiki page, here are more ways to find out about Reactive:
+
Besides this wiki page, here are more ways to find out about and get involved with Reactive:
  +
* Check out the series of Reactive tutorial posts beginning with ''[http://netsuperbrain.com/blog/posts/introducing-reactive-events/ Introducing Reactive: Events]''.
  +
* Contribute a tutorial to [[Reactive/Tutorials]]
 
* Read the paper ''[http://conal.net/papers/simply-reactive/ Simply Efficient Functional Reactivity]'' and its [http://conal.net/blog/posts/simply-efficient-functional-reactivity/ blog post with discussion].
 
* Read the paper ''[http://conal.net/papers/simply-reactive/ Simply Efficient Functional Reactivity]'' and its [http://conal.net/blog/posts/simply-efficient-functional-reactivity/ blog post with discussion].
* Read [http://darcs.haskell.org/packages/reactive/doc/html the Haddock docs].
+
* Join the [http://www.haskell.org/mailman/listinfo/reactive Reactive mailing list].
* Get the code repository: '''<tt>darcs get http://code.haskell.org/packages/reactive/</tt>'''.
+
* Visit the [http://hackage.haskell.org/cgi-bin/hackage-scripts/package/reactive Hackage page] for library documentation and to download & install.
* Install from [http://hackage.haskell.org Hackage].
+
* Or install with <tt>cabal install reactive</tt>.
* See the [[Reactive/Versions| version history]].
+
* Download the code repository: '''<tt>darcs get http://code.haskell.org/reactive/</tt>'''. Patches welcome.
  +
* Report bugs and request features on [http://trac.haskell.org/reactive/ the tracker].
  +
<!-- * Examine the [[Reactive/Versions| version history]]. -->
  +
  +
Reactive is intended to be used with a variety of "legacy" (imperative) libraries for graphics, GUI, robotics, web services, automatic recompilation and re-execution, etc. For an example of how to wrap up such libraries for use with Reactive, see the [[reactive-glut]] project.
  +
  +
The [[reactive-fieldtrip]] project connects Reactive and [[FieldTrip]].
  +
   
Please leave comments at the [[Talk:Reactive|Talk page]].
+
This page replaces [[old-reactive]].

Latest revision as of 10:39, 17 July 2011


[edit] Abstract

Reactive is a simple foundation for programming reactive systems functionally. Like Fran/FRP, Reactive has a notions of (reactive) behaviors and events. Some unusual features:

  • Much of the original interface is replaced by instances of standard type classes. In most cases, the denotational semantics of these instances is simple and inevitable, following from the principle of type class morphisms.
  • The original idea of reactive behaviors is composed out of two simple notions:
    • Reactive values are temporally discrete and reactive. They have a purely data representation, and so cache for free.
    • Time functions are temporally continuous and non-reactive.
  • Reactive provides and builds on functional futures, which are time/value pairs with several handy type class instances. Futures allow one to conveniently compute with values before they can be known, with a simple, purely functional semantics (no IO). Futures are polymorphic over both values and time, requiring only that time is ordered.
  • A particularly useful type of time, based on Warren Burton's improving values, reveals partial information in the form of lower bounds and minima, before the times can be known precisely. (Semantically non-flat.)
  • Improving values are implemented on top of a semantically simple unambiguous choice operator, unamb. Although unamb is built on Concurrent Haskell threads, the scheduler nondeterminism does not leak through (assuming the argument-compatibility precondition holds).
  • Reactive manages (I hope) to get the efficiency of data-driven computation with a (sort-of) demand-driven architecture. For that reason, Reactive is garbage-collector-friendly. (GC favors demand-driven computation.)


The inspiration for Reactive was Mike Sperber's Lula implementation of FRP. Mike used blocking threads, which I had never considered for FRP before a conversation with him at ICFP 2007. While playing with the idea, I realized that I could give a very elegant and efficient solution to caching.

Besides this wiki page, here are more ways to find out about and get involved with Reactive:

Reactive is intended to be used with a variety of "legacy" (imperative) libraries for graphics, GUI, robotics, web services, automatic recompilation and re-execution, etc. For an example of how to wrap up such libraries for use with Reactive, see the reactive-glut project.

The reactive-fieldtrip project connects Reactive and FieldTrip.


This page replaces old-reactive.