On Nov 24, 9:45 pm, kony <[email protected]> wrote: > On 24 Lis, 18:07, Krukow <[email protected]> wrote: > > > Three concurrent replies. We'd be better off using locks :-) > > Three concurrent replies but each of them brings something new ;) > Thank you very much for all of them! > > ... what is the use case,... I am just working on some kind of process > algebra simulator written in Clojure. Processes have to be interpreted > in the separate threads, so that is why that problem arose. > > BTW: another question is whether the behavior of resolve is a feature > or it is rather implementation error. Be honest I do not have opinion > in this matter. To little I know the Clojure.
It's not an error: vars have a root binding and thread local semantics (*ns* is root-bound to the clojure.core namespace, and in the repl thread it is bound to the user namespace). Since you are starting a new thread that thread sees the root binding. http://clojure.org/vars But you usually don't need to use resolve directly: (If in emacs, make sure you do M-x slime-redirect-inferior-output - if you don't, you won't see the threads output) user> (def zz 42) #'user/zz user> (.start (Thread. #(println zz))) 42 nil user> (.start (Thread. #(println (resolve 'zz)))) nil nil user> (.start (Thread. #(println (ns-resolve 'user 'zz)))) #'user/zz Regards, /Karl -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. 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
