On Mar 3, 8:04 am, Rich Hickey <richhic...@gmail.com> wrote:

>  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'.

Certainly you can and should hide the notion of current step for
*most* purposes. Using transactions is certainly a good way to do it;
but you must expose it in some way or you won't be able to express the
full range of dataflow models.

Typically:

;; pseudocode

(defmodel my-model
   (a :independent)
   (b (fn [a] (+ (* a 12) 3)))
   (c (fn [a] (+ a 7)))
   (d (fn [c b] (* c d 3.2))))

Here the step is implicit, as each reference to another cell in the
functions above really means "the value of that cell at the *same*
step/time/data pulse."  However:

1.  failing to deal with this issue in the *implementation* of a
dataflow
library leads to the wrong semantics; the absence of this notion or
any other means of dealing with it, (such as a transaction as you
suggest)
commonly leads to bugs in cells-alikes, including at least one clojure
implementation.

2. there are certain types of models where one needs to be able to
refer to previous pulses/steps. These include reflexive update
functions, (where the value of a cell depends on its own value at some
previous step/time/pulse), and time lags. With these types of
dependencies, there must be some way to explicitly refer to step or
pulse:

;pseudocode with time lag

((defmodel my-model
   (a :independent)
   (b (fn [a] (previous a 3))) ;; i.e., how many steps back
   (c (fn [a] (+ a 7)))
   (d (fn [c d] (* c d 3.2))))

You can certainly hide the most common case (i.e., everything is at
the same
step/pulse), but it has to be there internally or the semantics will
be
wrong, and it has to be exposed in some way or you won't be able to
express many interesting types of models in a simple, direct way.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to