On Mar 3, 1:58 am, Raffael Cavallaro <raffaelcavall...@gmail.com>
wrote:
> On Mar 2, 10:41 pm, Jeffrey Straszheim <straszheimjeff...@gmail.com>
> wrote:
>
> > First off, Clojure is not Common Lisp (to say the least), so I don't think
> > we necessarily need to create as stateful a library as the original Cells.
> > I've used Cells-like architectures before in GUI apps (although not as a
> > separate abstract library), and don't really think it is the best way.
>
> I can certainly imagine a functional interface such that any "cell"
> will
> return a value that is a function of time (or step) and other cell(s)
> at
> the same time/step:
>
> (value-at-step d 1000) = (d-func (value-at-step c 1000) (value-at-step
> b 1000))
>
> its crucial that all the other cells any cell depends on be at the
> same step
> as the step we're trying to compute before we do the computation or
> we end up with multiple updates for the same time/step in certain
> dependency graphs. IOW simply making one cell's value a function
> of the value of some other cell(s) and *not* also a function of step/
> time
> loses for certain dependency graphs.
>
> The "diamond" pattern is the classic example:
>
> a is independent (or draws its value from GUI input, etc.)
> b and c both depend on a
> d depends on b and c.
>
> a
> / \
> b c
> \ /
> d
> If we don't check the time/step/version of both b and c when a change
> to either triggers an update to d, we end up updating d twice, once
> with a broken value where only one of b or c is at the current step,
> and a second time with the correct value.
>
> I mention this because one the clojure cells-alikes had/has this bug.
>
> A functional interface to this sort of library would need to be
> stateful
> under the covers in order to avoid lots of recomputation with long
> dependency chains. Memoization is one simple means - memoize
> is in clojure already, and you could keep a functional
> interface while avoiding unnecessary recomputation of past state
> transitions.
I think it is important to embrace asynchrony and concurrency as
Clojure does. Any Cells-for-Clojure that presumes the world is a
single synchronous chain of events would be a misfit. The whole notion
of a 'current step' is suspect.
You have watches on all of the reference types. They all have
concurrency and coordination semantics. If B and C depend on A in such
a way that their values must be coordinated in order to be valid and
consistent, then maybe they shouldn't independently depend on A,
instead a transaction should fire on changes to A, which in turn
updates B and C. Then any downstream consumers of B and C could never
see inconsistent values, all without a notion of 'current step'.
An concurrent alternative to a master 'current step' notion for recalc/
already-seen/reconciliation etc would be something like vector clocks.
I know designing a multithreaded Cells is more challenging than a
single-threaded one, but the benefits are likely to be abundant. Much
of the plumbing already exists in Clojure + Java's concurrent queues.
Rich
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
