> I think that's the issue. Expecting your def-ed trantor to change once > the world state has been updated is what would be expected in a world > of pointers, OOP, etc. However, the new updated world (in my view) has > a new trantor which you need to extract with your (get-actor ...). > > This would all seem reasonable to me (modulo performance of updating > the world, etc.) since then you have many functions operating on a > single data structure and your flow is in terms of these functions > only. Meta-physics aside, if you have a single threaded app then a single lump of data is all you need. Each epoch follows the last along the single thread of execution, calculated at the CPU's leisure using the input state. If, on the other hand, you wish to run multiple threads, that you need to deal with concurrent updates and this is when Clojure's concurrency constructs come into play. How you actually partition the data behind refs or actors depends on the problem domain and the structure of your data; the refs and actors etc define your units of concurrent change. For an example you could look at the ants demo.
Alasdair -- 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
