Reactive programming: Difference between revisions

Content deleted Content added

Inline

Revision as of 12:03, 17 July 2007

Reactive programming is a programming paradigm oriented around interactive data flows. This means that it should be possible to express interactive data flows with ease in the programming languages used.

For example, in an imperative programming setting, $a:=b+c$ would mean that a is beeing assigned the result of $b+c$ in the instant the expression is evaluated. In reactive programming it could instead mean that we set up a dynamic data-flow from $b$ and $c$ to $a$ . Whenever the value of $c$ or $b$ is changed, then $a$ is automatically updated.

Reactive programming has foremost been propposed as a way to simplify the creation of interactive user interfaces and animations, but is essentially a general programming paradigm.

Data flow differentiation

In RP, ideally all data changes are propagated instantly, but this can generally not be assured in a realistic computational environment. So in the reactive programming paradigm, it might be necessary to distinguish different parts of the data flow graph, which have different evaluation priority. This could be called as diffrentiated reactive programming.

For example, in a word processor the marking of spelling errors need not be total in synch with the inserting of characters. This is a case where diffrentiated reactive programming potentially could be used, so that we could describe which data-flow that needs to be instant, and which can be delayed.

However, diffrentiating different areas of the data flow graph introduces a lot of additional design complexity. For example, how to define the different data flow areas, and how to handle invalidation in the border between different data flow areas.

Evaluation models of RP

Evaluation of FRP programs is not necessarily based on how stack based programming languages are evaluated. Instead, when some data is changed, the change is propagated to all data that is derrived partially or completley from the data that was changed. This change propagation could be achieved in a number of ways, where perhaps the most natural way is an invalidate/lazy-revalidate scheme.

One reason it would be problematic to just naively propagate a changes using a stack, is because of potential exponential update complexity if the data structure has a certain shape. One such shape can be described as "repeated diamonds shape", and has the following structure: A_n->B_n->A_n+1, A_n->C_n->A_n+1, where n=1,2...

One inherent problem for RP is that most computations that would be evaluated and forgotten in a normal programming language, needs to be represented in the memory as data-structures. This could potentially make RP memory consuming. However, research on what is called Lowering, could potentially overcome this problem. [1]

On the other side, RP is a form of what could be described as "explicit parallellism", and could therefore be beneficial for use on parallell hardware.

Reactive Imperative Programming

It is possible to fuse reactive programming with ordinary imperative programming. In such a paradigm, there would be imperative programs operating upon reactive data structures. Such a setup is analogous to constraint imperative programming, but where constraint imperative programming manages bi-directional constraints, reactive imperative programming just manages a-cyclic data-flows. Reactive imperative programming could be seen as the smaller brother of constraint imperative programming.

Object Oriented Reactive Programming (OORP)

OORP is a combination of object oriented programming and functional reactive programming. Perhaps the most natural way to make such a combination is as follows: Instead of methods and fields, objects have reactions that automatically reevaluate when the other reactions they depend on have been modified.

If an OORP programming language maintains its imperative methods, it would also fall under the category of imperative reactive programming.

Functional Reactive Programming

Functional reactive programming is reactive programming in the settings of functional programming langauges.

@@ Line 1: / Line 1: @@
 '''Reactive programming''' is a programming paradigm oriented around interactive data flows. This means that it should be possible to express interactive data flows with ease in the programming languages used.
-For example, in an imperative programming setting, <math>a := b + c</math> would mean that a is beeing assigned the result of <math>b + c</math> in the instant the expression is evaluated. In reactive programming it could instead mean that we set up a dynamic data-flow from <math>b</math> and <math>c</math> to <math>a</math>. Whenever the value of <math>c</math> or <math>b</math> is changed, then <math>a</math> is automatically changed also.
+For example, in an imperative programming setting, <math>a := b + c</math> would mean that a is beeing assigned the result of <math>b + c</math> in the instant the expression is evaluated. In reactive programming it could instead mean that we set up a dynamic data-flow from <math>b</math> and <math>c</math> to <math>a</math>. Whenever the value of <math>c</math> or <math>b</math> is changed, then <math>a</math> is automatically updated.
+Reactive programming has foremost been propposed as a way to simplify the creation of interactive user interfaces and animations, but is essentially a general programming paradigm.
+=== Data flow differentiation ===
+In RP, ideally all data changes are propagated instantly, but this can generally not be assured in a realistic computational environment. So in the reactive programming paradigm, it might be necessary to distinguish different parts of the data flow graph, which have different evaluation priority. This could be called as '''diffrentiated reactive programming'''.
+For example, in a word processor the marking of spelling errors need not be total in synch with the inserting of characters. This is a case where diffrentiated reactive programming potentially could be used, so that we could describe which data-flow that needs to be instant, and which can be delayed.
+However, diffrentiating different areas of the data flow graph introduces a lot of additional design complexity. For example, how to define the different data flow areas, and how to handle invalidation in the border between different data flow areas.
@@ Line 12: / Line 23: @@
 One inherent problem for RP is that most computations that would be evaluated and forgotten in a normal programming language, needs to be represented in the memory as data-structures. This could potentially make RP memory consuming. However, research on what is called '''Lowering''', could potentially overcome this problem. [http://portal.acm.org/citation.cfm?id=1244381.1244393]
+On the other side, RP is a form of what could be described as "explicit parallellism", and could therefore be beneficial for use on parallell hardware.