[reactive] FRP, continuous time and concurrency

[Conal Elliott]

>
> I'm trying to implement something like the Observer pattern in a functional
> setting. Some people told me that maybe I will find what I want in FRP. The
> Observer pattern enforces the propagation of changes [...]
>

One way to relate the Observer pattern (OP) to FRP is to view OP as an
imperative implementation of something like part of the functional semantics
of FRP.  Specifically, a *push*-based implementation (in contrast to most
previous FRP implementations).

>From this viewpoint, I suggest changing your goal.  Instead of "trying to
implement something like the Observer pattern in a functional setting", you
might try to identify a *functional* idea that serves the same purposes as
OP (and implement it however you want, e.g. push and/or pull).  Or you might
use OP as a (hidden, imperative) implementation of some functional idea.
Likely both.

Unless you're terrifically careful, I expect OP will lead you to incorrect
implementations of FRP (which is fine if you're not trying to implement FRP
or something else with simple & precise semantics).

I first tried to implement FRP via OP (push) in 1998 (see ref in
http://conal.net/papers/simply-reactive/), and I was unable to get the FRP
semantics correct at the time.  Coming home from ICFP 2007, after chatting
with Mike Sperber, I got the idea for Reactive.  The implementation approach
in Reactive is not classical push.  It's a highly-multithreaded pull, in
which most threads are blocked most of the time.  I had always thought that
push==data-driven, and pull==demand-driven, but Reactive is data-driven pull
(made possible by multi-threading).  The threading is hidden inside the
implementation of unamb.

Regards,  - Conal


2009/6/8 Álvaro García Pérez <agarcia at babel.ls.fi.upm.es>

> Hello,
>
> I'm trying to implement something like the Observer pattern in a functional
> setting. Some people told me that maybe I will find what I want in FRP. The
> Observer pattern enforces the propagation of changes in the subject to the
> observers, but in a way where concurrency is not considered, through the
> notify-update mechanism. Time is not considered because the updating methods
> are invoked in a synchronous way. Other way to say it is that time is a
> discrete value which is incremented by one with any subject change and the
> observers use a pooling strategy in every instance of time. The subject and
> the observers operate in the same thread.
>
> As far as I've seen (but I'm not sure if I'm right) FRP models behaviours
> and time as continuous entities (although practical implementations use
> discrete time and discrete sampling in event detection). You must represent
> the time explicitly and concurrency is used to model behaviors and events.
> Is there any interpretation of FRP without using concurrency? Can the time
> be modeled in a discrete fashion (as described for the Observer pattern)? I
> didn't find any example of that. Is it possible to model something like the
> Observer patern using the standard FRP conventions? Are these situations
> inside the aims of FRP?
>
> I think the Observer pattern and FRP are related somehow, but I cannot
> figure out how is this.
>
> Alvaro.
>
> _______________________________________________
> 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/20090610/e9ce8041/attachment.html