On Mon, Jan 19, 2009 at 11:01 PM, Stuart Halloway <stuart.hallo...@gmail.com> wrote: > > Lazy evaluation is a harsh mistress. > > user=> (def b1 (binding [*num* 1024] (f1))) > #'user/b1 > user=> (def b2 (binding [*num* 1024] (f1))) > #'user/b2 > user=> b1 > (16) > user=> b2 > (16) > > The difference between the example above and your example is the > interaction with the REPL. Your f1 is lazy, and is not realized until > outside the binding, when the REPL needs it. Your f2, also lazy, is > realized inside the binding because of the call to first. >
OK, good, thanks for the explanation. Is it desirable behavior? Is there some case where a programmer wants this behavior? It's pretty scary to have to consider these hidden effects. Sort of the opposite of FP. My gut tells me I want to get the same results evaluating lazily or eagerly, is that reasonable? Doesn't seem practical to use bindings if it can bite you like this. BTW in the actual case that bit me, a function inside another anonymous function, all inside a macro, used the stale value of the Var. IOW it wasn't a case of evaluating at the repl. The f1 I posted here was an attempt to simplify that case, but it's maybe too simple to demonstrate the full problem. Hugh > Cheers, > Stuart > >> Hi all. Is this a bug or a feature? When I bind the var *num* to a new >> value, in one case it appears the lambda uses the original value, not >> the newly bound one. >> >> (def *num* 16) >> >> (defn f1 [] >> ( map (fn [x] *num* ) [1])) >> >> >> (defn f2 [] ;; same as f1 but calls first on the map >> (first >> ( map (fn [x] *num* ) [1]))) >> >> >> user> (f1) >> (16) <--ok >> user> (f2) >> 16 <--ok >> user> (binding [*num* 1024] (f1)) >> (16) <-- >> expected 1024 >> user> (binding [*num* 1024] (f2)) >> 1024 <--ok after >> all, in spite of the fact the above gave list (16) >> >> Thanks, >> Hugh >> >> > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
