> One problem then is that the work becomes explicit instead of implicit as it is in Clojure: future and agent sends setup the machinery for you.
You need the ability to explicitly capture and restore the current thread bindings to implement that implicit machinery. The future macro is implemented in terms of future-call, which is implemented in terms of binding-conveyor-function, which is very similar to bound-fn. I still need to examine the differences a bit more, but it looks like binding-conveyor-function may just be an optimization to avoid re-validating already validated dynamic bindings. ClojureScript doesn't have future-call or agents yet, but if they (or similar constructs) are to be implemented correctly, you need the ability to save and load a binding frame. That's what my changes accomplish. > Another problem with the proposal is that there will be use cases for dynamic binding that shouldn't have to pay for the overhead of your implementation. What use cases do you have in mind? I haven't done any benchmarks, but the implementation closely follows JVM Clojure's implementation. As far as I can tell, the same fees are paid for every Var in every Clojure app. The cost of those fees may vary, but there is a bunch of room for optimization. Basically, the current implementation of the binding that's in the master branch is much more similar to the with-redefs macro. Couldn't people who don't need async dynamic bindings, but need the perf simply use that? (I could implement it on this branch) -- 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
