[reactive] FRP, continuous time and concurrency

[Eyal Lotem]

I believe there's also an issue of pull potentially creating large space
leaks (where some input accumulates because nobody is pulling it), as well
as perhaps aggregating processing time that will be paid at a single point
when the value is actually pulled.

Eyal

2009/6/9 Peter Verswyvelen <bugfact at gmail.com>

> Basically this is also referred to as "push" versus "pull". The way I
> understand it: pushing means that when a source (= the real inputs, aka
> sensor, e.g. mouse) changes, it notifies its dependencies about this change.
> At the lowest level pushes are caused by interrupts, at the high level this
> is typically represented in OO by subject/observer (aka signals/slots, aka
> events in .NET). Pulling means that you read a value from the final output
> "node" (e.g. the voltage of a motor or a 3D object to be displayed on the
> screen), this node reads its inputs, until it samples the value of a sensor.
> Pulling has the advantage that only those values that are needed are
> computed, but has the disadvantage that all these values will always be
> recomputed.
>
> Pushing has that advantage that only those values that change cause other
> values to be updated, but has the disadvantage that the values that are
> updated are actually not needed in the output, or that other changes can
> cause redundant updates.
>
> I believe Reactive actually tries to find a good balance between push and
> pull: a reactive value (which basically is a value sampled at discrete
> points in time) is only recomputed when any of its inputs changes.
> Grapefruit also does this but uses a completely different approach.
>
> My personal opinion is that you cannot statically determine which strategy
> is best (and where to insert nodes that cache values), one would need to do
> perform profiling to measure the change frequency of sensors (and
> dependencies) in a typical scenario. Of course sensors could have an
> estimated change frequency that would help at compile time. For example when
> playing a videogame the change frequency of the analog stick is very high,
> while that of the joypad buttons is much lower.
>
>
>
> 2009/6/9 Álvaro García Pérez <agarcia at babel.ls.fi.upm.es>
>
>> Hi,
>>
>> When talking about the Observer pattern I was thinking in the case that
>> appears in the reactive programming entry in Wikipedia (
>> http://en.wikipedia.org/wiki/Reactive_programming).
>>
>> If we have a reactive setting then the sentence
>> a := b + c
>> could mean that there is a dynamic data flow from the values b and c to
>> the value a, so whenever b or c change, a is automatically changed.
>>
>> 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.
>>
>> It seems that some goals of reactive programming are shared with the goals
>> of the Observer pattern. Are they actually related? Maybe this relationship
>> is between the pattern and reactive programming in general, not FRP. Is this
>> so or is Wikipedia just wrong about that? Anyway, is it possible to
>> implement something alike the a := b + c case using Reactive or any oher FRP
>> package? Can someone show any example?
>>
>> Thanks,
>>
>> Alvaro.
>>
>>
>> ---------- Forwarded message ----------
>> From: Patai Gergely <patai_gergely at fastmail.fm>
>> Date: 2009/6/9
>> Subject: Re: [reactive] FRP, continuous time and concurrency
>> To: Álvaro García Pérez <agarcia at babel.ls.fi.upm.es>,
>> reactive at haskell.org
>>
>>
>> Hi Alvaro,
>>
>> > Observer patern using the standard FRP conventions? Are these situations
>> > inside the aims of FRP?
>> There are several flavours of FRP that approach reactivity from
>> different angles. I'd say Grapefruit is the one most relevant to the
>> Observer pattern, since it models complex systems as a network of
>> interconnected circuits, where circuits are effectful entities, and they
>> can communicate through both discrete and continuous signals. The other
>> system that might be relevant is Yampa, since you model entities as
>> stateful signal functions (but unlike in Grapefruit they cannot perform
>> side effects), and connect them however you want. Incidentally, both of
>> these approaches are arrow based.
>>
>> In contrast, Reactive aims to describe the (output over the) whole
>> lifetime of an entity as a pure value. Dependencies between entities are
>> established simply by defining one as a function of the other, and
>> mutual dependencies are naturally allowed. I don't think there's any
>> meaningful way to connect the Observer pattern to that. In fact, the
>> basic OO design patterns are often meaningless in functional
>> programming, because it's a completely different world.
>>
>> Gergely
>>
>> --
>> http://www.fastmail.fm - Or how I learned to stop worrying and
>>                          love email again
>>
>>
>>
>> _______________________________________________
>> Reactive mailing list
>> Reactive at haskell.org
>> http://www.haskell.org/mailman/listinfo/reactive
>>
>>
>
> _______________________________________________
> Reactive mailing list
> Reactive at haskell.org
> http://www.haskell.org/mailman/listinfo/reactive
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/reactive/attachments/20090609/35363b70/attachment.html