Time for another person named Mark to chime in. I expect to hear from all the other Marks before this thread is over.
I have three responses to your suggestion: 1. Data: Is this really a problem that is slowing down Clojure programs in practice? Can you provide some data to that effect? I would suggest writing a couple of Java benchmarks - one that updates a simple structure in place and one that only creates new data. Time them. Write more benchmarks, but this time do it in Clojure (though perhaps with some straight Java calls to make the updates). Are there differences in the Java versions from the Clojure versions? Are there differences in the update vs new data versions? My intuition is that you are not going to see a big speed up for this, but let's put the hypothesis to the test. As I understand it, short lived data is cheap to make and discard, as the copying collector doesn't have much to do if nursery data is discarded quickly. But, of course, there are costs to allocation, etc. Perhaps I am wrong. I would be interested to see data on the subject. 2. Take a page from the Scheme playbook. Don't ask the language to implement this feature, ask for the minimal set of tools that you need to implement it. I would think a code walking escape analysis macro could be very useful. Instead of run-time reference counting, the macro could find data that is guaranteed not to escape its scope via a closure (e.g. let bound locals that are not used in any (fn [] ...)s ). What would you need access to? Additional JVM byte-code instructions? Post-compile processing by user code? Update in place methods for the normally immutable types? I don't know exactly what you'd need, but ask for that before asking for a much bigger feature. 3. Remember that Clojure relies on the JVM for its allocation and GC. Clojure is not issuing malloc and free calls. The JVM will not make it easy to repurpose the storage of one object with a new object, without going through a method. As I see it, all functions would require an update-in-place version. The compiler could swap these behind the scenes, but writing them would be a lot of work. I could be wrong about this, as I am not a JVM expert, but without direct access to pointers, how else would this be accomplished? All in all, an interesting research topic -- especially if data show that a big speed up could be found by implementing it. Best of luck, -Mark On Jan 7, 2009, at 8:01 PM, Mark P wrote: > > I am new to clojure, but it seems very interesting. > > Has anyone thought about allowing "update in place" > for situations where it is safe? > > Suppose you have > > (def y (tripleit x)) > > and you know that there is only a single reference to x > at this point, then it would be safe to implement it as > > "y takes on the storage of x and this is multiplied > by 3 in-place". > > Well, I should say it's safe as long as "x" loses scope > at this point. The fact that y has gained its storage and > done an update in place shouldn't bother anyone or > cause any loss in purity. > > This is what "uniqueness types" are used for in the > "Clean" functional lanugage. (And logic language > Mercury uses "unique modes".) > > Now I realize there is the question in Clojure of > "how do we know whether it's unique". Clean does it > via the type system. But one could have other > mechanisms for ensuring uniqueness. One would be > to keep a runtime track of references and only allow an > update-in-place primitive in the case of a single reference. > If this were attempted when multiple references existed, > a runtime error would occur. > > Has anyone thought about this kind of update-in-place > methodology? It seems to be one of the reasons why > both Clean and Mercury achieve good performance. > > Perhaps there are good reasons why this approach is > not workable in clojure (or not useful), but I'd be > interested to hear why. > > Thanks, > > Mark. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
