Hi Tim, I appreciate your comments.
> It is possible to achieve this behavior explicitly if you really > wanted to: > (defn create-add-2 [] > (with-local-vars [x 1] > (do > (var-set x 1) > (var-set x (inc @x)) > (let [z @x] > (fn [y] (+ y z)))))) That's true. Only the "(inc @x)" isn't update-in-place. Presumably some java something could be used here instead to get true update in place. > Such an aggressive optimizer might be unhappy with a runtime check and > opt for an unsafe mutable: > user=> (def p (java.awt.Point. 0 0)) > #'user/p > user=> p > #<Point java.awt.Point[x=0,y=0]> > user=> (.setLocation p 1 2) > nil > user=> p > #<Point java.awt.Point[x=1,y=2]> > But might still be unhappy with having to use object calls, at which > point I don't think Clojure is the right language. However lucky for > them they could still go away and implement an incredibly efficient > java api and call it from within Clojure very easily. They would still > want to wring the last few drops of performance and write it in C. > Actually they could still invoke that code at a high level via JNI but > of course would want to keep the calls to a minimum to avoid calling > overhead. What you're saying could well be true. Ie a runtime check of unique reference might not be acceptable where performance is a major concern. But there are two ways around this. 1. Have the ability to turn runtime uniqueness checking on or off. This way code can be tested with the check on, but then run with it off once we are convinced the code is correct (at coder's own risk of course). 2. Take up Mark Fredrickson's suggestion of a code walking analysis macro to prove uniqueness before running the code. That way no runtime check is needed. The fact that java method calls are always expensive is still a problem though. As you say, ultimately a call to a C or C++ routine via JNI might be the only real performance answer. I wish there were a better way. > I'm just an observer, but if I can't see such a feature appealing to > "the performance user" because it wont ever be as fast as they want it > to be. To appeal to the general user transparent implementation, which > it can't be if you want to preserve all the features. A subset between > these exist, but is quite small and not a far step from moving up or > down. You might be right here, though I still feel uniqueness is a good tool for writing safe and somewhat transparent "equivalent to mutation" based code. C++ is (unfortunately) my current main language and I use a runtime uniqueness framework to ensure much more reliable mutation based code there. But I think Java's insistence on virtual function calls may make a highly efficient uniqueness approach difficult to achieve in Clojure. > > * uniquely-referenced (arbitrary mutation changes effectively > > allowed, but only ever referred to uniquely (runtime enforced)). > > I think that pretty accurately describes C++, its not fun debugging a > runtime enforced coredump full of crap. :) > I know that's not what your proposing sorry but I couldn't resist the > analogy! I'm not saying its a bad idea, I just don't find it > compelling to me personally. But adhering to a uniqueness discipline within C++, together with a functional approach like FC++, does lead to more reliable and more transparent (and somewhat efficient) C++ code. And uniqueness in a lisp language should be much more elegant than my C++ implementation. But I think you and Mark Fredrickson are right to point out that limitations within the JVM itself may make efficiency via uniqueness that is competative with C/C++, impossible to achieve. I'm still hopeful there may be a way, but I can't see it just now. 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 -~----------~----~----~----~------~----~------~--~---
