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@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@haskell.org
http://www.haskell.org/mailman/listinfo/reactive