Assuming no need for coordination, atoms are a fine substitute for
refs, but the structure should be similar to Laurent's example (thus
avoiding conflation of identity and state), namely the var (e.g., n0,
n1) should be an atom of a map containing atoms. E.g.,
user=> (defn set-in! [node in] (dosync (swap! node assoc :in in)))
#'user/set-in!
user=> (defn set-out! [node out] (dosync (swap! node assoc :out out)))
#'user/set-out!
user=> (set! *print-level* 3)
3
user=> (def n0 (atom nil))
#'user/n0
user=> (def n1 (atom nil))
#'user/n1
user=> (set-in! n1 n0)
{:in #<a...@bdccedd: nil>}
user=> (set-out! n0 n1)
{:out #<a...@5a199939: {:in #}>}
user=> n0
#<a...@bdccedd: {:out #<a...@5a199939: #>}>
user=> n1
#<a...@5a199939: {:in #<a...@bdccedd: #>}>
On Jul 2, 2:45 pm, Greg <g...@kinostudios.com> wrote:
> This probably isn't the right way to do it, but it works:
>
> user=> (def n0 {:in (atom ()) :out (atom '(#'n1))})
> #'user/n0
> user=> (def n1 {:in (atom '(#'n0)) :out (atom ())})
> #'user/n1
> user=> (swap! (:in n0) conj '#'n3)
> ((var n3))
> user=> n0
> {:in #<a...@47ef7de4: ((var n3))>, :out #<a...@3c3228a1: ((var n1))>}
> user=> @(eval (first @(:in n1)))
> {:in #<a...@47ef7de4: ((var n3))>, :out #<a...@3c3228a1: ((var n1))>}
>
> I'm not sure whether it's faster to use eval in this case, or the whole STM
> thing.
>
> Thoughts?
>
> Disclaimer: I'm a n00b too! :-p
>
> On Jul 2, 2010, at 5:21 PM, Laurent PETIT wrote:
>
>
>
> > I've also struggled with the same concepts in my head in the past.
>
> > One answer to try explain why it is not possible, is that if you do
> > that, you somehow try to conflate identity and state again.
>
> > When you write n0: in () out (n1) and n1 in(n0) out() , it seems to me
> > that when you write n0:in() out(n1) you're thinking about n0 as the
> > node(identity)+state (value of an identity at a point in time)
> > conflated, but when you write n1 in(n0) out(), you think about n0 as
> > the identity.
>
> > So in fact, if I try to separate identity and state again, n0 and n1 are
> > refs:
> > (def n0 (ref nil))
> > (def n1 (ref {:in [n0], :out []}))
> > (dosync (ref-set n0 {:in [], :out [n1]}))
>
> > Or you could manage by yourself the concept of identity, not
> > delegating it to clojure's refs, as you said.
>
> > 2010/7/2 Mate Toth <totm...@gmail.com>:
> >> I'm building a directed graph library, where the nodes has "out" and
> >> "in" fields. If I connect a node, let's say:
> >> (node->node n0 n1)
> >> then the node's fields would be the following:
>
> >> n0:
> >> in: ()
> >> out: (n1)
>
> >> n1:
> >> in: (n0)
> >> out ()
>
> >> My problem is that if I update n0 I could only add the old "instance"
> >> to the list, so when I update n1, n0's out field would would contain
> >> an outdated n1 also..
>
> >> So n00b head I think it's out of the functional paradigm(or I could
> >> use node-ids and a hash as a graph, but I don't like it), but how you
> >> guys would solve this problem? Any workaround?
>
> >> Thanks for your help! M
>
> >> --
> >> 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
>
> > --
> > 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
--
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
