> Clojure gives you a set of data structures that do very fast > non-destructive update. Clojure also gives you tools like atoms, > refs, and full access to Java's mutable behavior to specify update in > place if that's what you want.
Yes, I can see that one could implement this oneself via Java. But it wouldn't be an official part of the language. What I am wondering is whether update-in-place for unique references could lead to greater efficiencies (in some cases) than Clojure's current non-destructive updates. And without harming referential transparency or concurrency benefits. Fundamentally I would have thought update-in-place beats update-by-replace in both execution speed and in memory usage. The only problem with it is that it usually breaks referential transparency as well as causing problems with concurrency. But in the case of a unique reference that is about to disappear, update-in-place does no harm! The memory is about to become obsolete soon anyway so why not commandeer it? And if commandeered, why not update it in place - as nothing else is looking at it. I realize there are issues, but maybe these could be solved and it could lead to even more efficient (both time and memory) code from Clojure, while not sacrificing its strengths. I'm just wondering whether anyone has thought about it. And if so, whether it has potential, or whether there are good reasons why it is not practical. Cheers, Mark P. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
