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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > 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) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
