Reactive Programming in F# and CELLs

[falcon]

I hope folks here don't mind this post. The following article
explains how to do reactive programming in F#:
http://tomasp.net/blog/reactive-i-fsevents.aspx (the bottom of the
article has links to rest of the articles in the series)

There has been some recent discussion on CELLs in Clojure. There was
some question of motivation behind 'reactive' programming...I believe
this article makes the ideas a bit more concrete. Since Clojure
already has some features for concurrent programming, I believe the
reactive model should also be easy to accommodate.

In F#, one can filter/map/reduce events (and much more) just as if
they were operations on a list. How would this be done in cells? How
would one combine or split several cells?

This type of data-flow programming also brings clojure one step closer
my dream of a super-spreadsheet: Instead of typing out expressions on
an REPL, why not make the REPL non-linear and allow users to enter
expressions in 2-d space (similar to a grid...but without the grid).
Unlike Excel, clojure could also very easily let end-users define
their own functions and use them in expressions (thereby vastly
improving the lack of abstractions in current spread sheets)

[Stuart Sierra]

Hi, falcon,
I wrote (with MikeM) a pair of basic Cell-like libraries in Clojure,
one using Refs and one using Agents:
http://groups.google.com/group/clojure/browse_thread/thread/d79392e4c79f8cde
(code is in the attachments)

In response, Rich added Agent Watches (see same thread), which are
like triggers that get called whenever an Agent's value changes. I'm
not sure where else to go with this, but I'm interested in talking
about it.

One thing I was never clear on was the correct transactional
behavior. With cells in Refs, modifying a cell blocks until all other
cells are up-to-date, which can take time. With cells in Agents,
modifying a cell never blocks, but you can't predict the order of
events, as I discovered with a simple GUI demo.

I know the original Common Lisp version of Cells imposed a global time
counter, so it may be a dependency framework rather than a concurrency
framework. From Rich: "I don't know anything about Cells, but if it
has global time ordering it might not be a good fit for
multithreading, and not for agents."

-Stuart Sierra

On Nov 24, 7:33 pm, falcon <shahb...@gmail.com> wrote:
> I hope folks here don't mind this post.  The following article

> explains how to do reactive programming in F#:http://tomasp.net/blog/reactive-i-fsevents.aspx(the bottom of the

[falcon]

I did see the Cell discussion and noticed that Rich added the ability
to watch Agents. Sounds like maintaining correct dependencies is more
important than raw speed. I believe this problem of maintaining
correct dependencies is called "Glitch Prevention" in FrTime
framework.

The FrTime papers are quite interesting (ftp://ftp.cs.brown.edu/pub/
techreports/03/cs03-20.pdf, http://www.cs.brown.edu/~sk/Publications/Papers/Published/ck-frtime/paper.pdf).
There is even an FrTime library which has a few years of work behind
it: http://download.plt-scheme.org/doc/pdf/frtime.pdf. I get the
impression that FrTime is more fully baked than Cells.

By the way, even if dependency has to be maintained, as long as there
are several independent dependency graphs, the system should still be
able to process them concurrently.

You mentioned that you weren't sure where to go with this. I think a
framework like this could be the foundation of many interesting
features. Academic literature often associates reactive programs with
GUI programming. You will find plenty of takers in the finance
industry, who have to react to multiple streams of data (changing
prices, order status, etc.). Complex event processing is becoming a
more mature field and is used for tracking RFID chips (at super
markets, ports, etc.). I think the most obvious use is spreadsheets.
Spreadsheets basically operate on a data-flow programming model such
as this. Finally, with Rich's background in simulation, I would think
he would be more interested in this than most :)

On Nov 25, 10:00 am, Stuart Sierra <the.stuart.sie...@gmail.com>
wrote:

> Hi, falcon,
> I wrote (with MikeM) a pair of basic Cell-like libraries in Clojure,

> one using Refs and one using Agents:http://groups.google.com/group/clojure/browse_thread/thread/d79392e4c...

> (code is in the attachments)
>
> In response, Rich added Agent Watches (see same thread), which are
> like triggers that get called whenever an Agent's value changes.  I'm
> not sure where else to go with this, but I'm interested in talking
> about it.
>
> One thing I was never clear on was the correct transactional
> behavior.  With cells in Refs, modifying a cell blocks until all other
> cells are up-to-date, which can take time.  With cells in Agents,
> modifying a cell never blocks, but you can't predict the order of
> events, as I discovered with a simple GUI demo.
>
> I know the original Common Lisp version of Cells imposed a global time
> counter, so it may be a dependency framework rather than a concurrency
> framework.  From Rich: "I don't know anything about Cells, but if it
> has global time ordering it might not be a good fit for
> multithreading, and not for agents."
>
> -Stuart Sierra
>
> On Nov 24, 7:33 pm, falcon <shahb...@gmail.com> wrote:
>
> > I hope folks here don't mind this post.  The following article

> > explains how to do reactive programming in F#:http://tomasp.net/blog/reactive-i-fsevents.aspx(thebottom of the