[reactive] FRP, continuous time and concurrency

Álvaro García Pérez agarcia at babel.ls.fi.upm.es
Wed Jun 10 06:20:21 EDT 2009


I agree that there are some issues about the cyclic dependencies with the
observer pattern, but I think that considering it a glitch or not is a
matter of phylosophical discussion. In Daniel's example you will end with
the proper value in "a" (even if you have an inproper value for some
negligible instants). You only may consider this a problem if your system
has poles near those values, which can turn it into a diverging system, and
if the updating period is big enough to trigger those diverging effects. For
almost any non real-time-control system this is not alike to happen. And of
course, you can implement your own Observer patern imposing some policies in
the update ordering, which can help to avoid the glitches.

Anyway, can you give any implementation of this example using the reactive
library? I'm interested in how to code this, as far as I don't know the
paradigm and the libraries. Can someone sketch a code where the reactive
variables (a := b + c ...) or something alike is implemented? Even a trivial
example will fit me, I just want to know how to translate this into code.

Thanks,

Alvaro.

2009/6/9 Daniel Bünzli <daniel.buenzli at erratique.ch>

> I don't think the push/pull issue is relevant to the discussion about frp
> and the OO observer pattern. The push/pull issue is an (important)
> implementation detail of FRP.
>
> Le 9 juin 09 à 19:09, Álvaro García Pérez a écrit :
>
>  This has similarities to the OO Observer pattern (in fact, you can
>> implement it using the pattern) and is also supported in some new scripting
>> languages as JavaFX.
>>
>
> One thing the observer pattern doesn't give you is any guarantee on the
> order of updates: when the observed value changes it updates all the
> observers in no specified order. However if a value observes more than one
> value this may result in glitches (i.e. values you actually don't want to
> see).
>
> For example suppose your value dependencies are as follows :
>
> a = b + c
> b = c + 1
>
> i.e. a observes b and c, and b observes c and initially we have :
>
> c = 0
> b = 1
> a = 1
>
> If c updates from 0 to 2 any of the following two sequences of updates may
> be seen with the OO observer pattern :
>
> c = 2; a = 3; b = 2; a = 4;
> c = 2; b = 2; a = 4;
>
> But usually you don't want to see the a = 3, it's a glitch. FRP systems
> update the graph of dependencies in topological order (i.e. they ensure
> before updating a value that each value it depends on has been updated) and
> you are guaranteed you'll only see the second sequence of updates.
>
> FRP can be seen as a form of value observation in the sense that changes in
> a value get eventually propagated to other values that depend on it. But it
> is clearly not the same as the OO observer pattern as usually
> understood/implemented because of this ordering issue. FRP is more subtle
> and powerful in the management of the value's dependency graph.
>
> Best,
>
> Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/reactive/attachments/20090610/ca57dc8d/attachment.html


More information about the Reactive mailing list