Hi,
I really like the idea of grouping mutation in my programs into
transactions in order to reduce the number of possible states make
make reasoning about them easier (in the spirit of the mutable state
discussion of [1]) and thought that Clojure's "dosync" + refs might be
the ideal way to do this. However, I was disappointed to find out the
following:
(def r (ref 1))
(dosync
(alter r #(+ 1 %))
(println @r))
(println @r)
Output:
2
2
I would have hoped that changes to refs during an transaction wouldn't
affect the in-transaction value of the ref (that is, I would have
liked the code to print 1, then 2). This way, the view of the
program's state would always be guaranteed to be consistent, even
during a transaction, and there would be no fear of non-consistent in-
transaction states breaking anything. The way it is currently work in
Clojure, though, still requires one to take all such inconsistent
states into account, rendering them effectively useless for the kind
of state management I imagined.
(Note that I am not talking about multi-threading here; my objective
is to reduce the number of possible states in the single-threaded
case, and make sure that every computation is based upon a consistent
state.)
Why was this behavior chosen, instead of only making changes to refs
invisible until commited (even to the transaction commiting them)? I
believe that the latter approach would actually fit better to Clojure
in general. Maybe there could at least be an alternative "dosync" form
that acts like this?
Regards,
Denis
--
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
Note that posts from new members are moderated - please be patient with your
first post.
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
