Clojure 1.3 Alpha 2
Stuart Halloway
http://clojure.org/downloads
ka
Please explain this!
Baishampayan Ghose
>
>> code path for using vars is now *much* faster for the common case, and you must explicitly ask for :dynamic bindability
Earlier vars were looked up each time they were accessed inside
functions because there was no way of telling if it was being
dynamically rebound or not. Now all vars are cached inside function
calls and are not looked up every time. To be able to dynamically
rebind vars, the metadata :dynamic needs to be present in which case
the vars will be looked up when they are rebound. For global
(non-dynamic) vars, there is a universal var counter which is
incremented each time a var root is altered and when that change is
detected inside functions, they lookup the vars again. Since the
function would use the cached var values happily if the global var
counter is unchanged, they are now way faster.
I hope that helps.
Regards,
BG
--
Baishampayan Ghose
b.ghose at gmail.com
nickikt
then you will get information on this.
Lee Spector
On Oct 25, 2010, at 3:44 PM, Stuart Halloway wrote:
> * code path for using vars is now *much* faster for the common case,
> and you must explicitly ask for :dynamic bindability
This has been bouncing around in my head for the last week or so, occasionally colliding with the memory of Rich Hickey showing dynamic rebinding of vars during a run (in a video, maybe on the ant simulation?) and saying something like "It's a dynamic language!" (apparently with approval).
I understand how this can be a big win on performance and I guess it's a minor sacrifice since one will still be able ask for dynamic bindability with only a little more clutter.
But it leads me to ask whether it would be possible to simultaneously provide a way to load libraries (e.g. in require or :require clauses of ns) while specifying that certain vars in the library are to be defined as dynamically bindable, even if they're not coded as such within the library.
The reason I ask is that I often create a library and then want to use it in a context in which I want one of the library's internal subfunctions to be defined differently. So I load the library and then redefine the subfunction's var (sandwiched between calls to ns, so I'm redefining the var in the right namespace). [Perhaps this is not a recommended way to do things? In any event I find it useful... Is there a better way that's not a lot more work?]
Anyway, I don't know ahead of time, when I write the library, which particular vars I might want to redefine for any particular application/experiment. But I'd rather not change the library's code between experiments; I'd like that to be frozen and constant (and I use the exact same file for many experiments). So if I wanted to make this work in all possible use cases I'd have to designate *all* of my vars as dynamically, but then: A) I'd have to clutter all of my vars with :dynamic specifications and, 2) I'd lose the optimizations that this new feature of 1.3 alpha 2 are providing (which sound worthwhile, being "*much* faster"). It would be nicer if I could define everything in the library in the normal way, and have everything loaded as not-dynamically-bindable in the usual case, but if I could say in a particular application file that loads the library something like:
(ns foo
(:require [bar :dynamic baz bingo]))
Or something to that effect -- I don't know if this exact syntax is consistent with the various options in an ns/require form.
The idea is that this would load bar but with the definitions of baz and bingo marked as dynamically bindable, even though the code in bar.clj doesn't ask for dynamic bindability.
Possible? Desirable?
Thanks!
-Lee
Laurent PETIT
2010/11/5 Lee Spector <lspe...@hampshire.edu>:
>
> On Oct 25, 2010, at 3:44 PM, Stuart Halloway wrote:
>> * code path for using vars is now *much* faster for the common case,
>> and you must explicitly ask for :dynamic bindability
>
> This has been bouncing around in my head for the last week or so, occasionally colliding with the memory of Rich Hickey showing dynamic rebinding of vars during a run (in a video, maybe on the ant simulation?) and saying something like "It's a dynamic language!" (apparently with approval).
>
> I understand how this can be a big win on performance and I guess it's a minor sacrifice since one will still be able ask for dynamic bindability with only a little more clutter.
>
> But it leads me to ask whether it would be possible to simultaneously provide a way to load libraries (e.g. in require or :require clauses of ns) while specifying that certain vars in the library are to be defined as dynamically bindable, even if they're not coded as such within the library.
>
> The reason I ask is that I often create a library and then want to use it in a context in which I want one of the library's internal subfunctions to be defined differently. So I load the library and then redefine the subfunction's var (sandwiched between calls to ns, so I'm redefining the var in the right namespace). [Perhaps this is not a recommended way to do things? In any event I find it useful... Is there a better way that's not a lot more work?]
If I understand well, you are re-def'ing the var. If so, then no
problem, because you have mistaken "redefinition of a var" for
"dynamic rebinding of a var".
redefinition of a var will still be possible for non dynamically
rebindable vars. (or we could then just stop to work on the REPL with
Chas !)
>
> Anyway, I don't know ahead of time, when I write the library, which particular vars I might want to redefine for any particular application/experiment. But I'd rather not change the library's code between experiments; I'd like that to be frozen and constant (and I use the exact same file for many experiments). So if I wanted to make this work in all possible use cases I'd have to designate *all* of my vars as dynamically, but then: A) I'd have to clutter all of my vars with :dynamic specifications and, 2) I'd lose the optimizations that this new feature of 1.3 alpha 2 are providing (which sound worthwhile, being "*much* faster"). It would be nicer if I could define everything in the library in the normal way, and have everything loaded as not-dynamically-bindable in the usual case, but if I could say in a particular application file that loads the library something like:
>
> (ns foo
> (:require [bar :dynamic baz bingo]))
>
> Or something to that effect -- I don't know if this exact syntax is consistent with the various options in an ns/require form.
>
> The idea is that this would load bar but with the definitions of baz and bingo marked as dynamically bindable, even though the code in bar.clj doesn't ask for dynamic bindability.
>
> Possible? Desirable?
>
> Thanks!
>
> -Lee
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
Lee Spector
On Nov 5, 2010, at 4:43 PM, Laurent PETIT wrote:
>
> If I understand well, you are re-def'ing the var. If so, then no
> problem, because you have mistaken "redefinition of a var" for
> "dynamic rebinding of a var".
>
> redefinition of a var will still be possible for non dynamically
> rebindable vars. (or we could then just stop to work on the REPL with
> Chas !)
Ah -- beautiful.
I completely misunderstood and was "borrowing worries," as we say in my family.
Maybe it's from my time in the Lisp/Scheme world, where "binding" in used more broadly (I think!).
Thanks so much!
-Lee