On Nov 17, 2010, at 9:22 AM, Stuart Halloway wrote: > In 1.2, functions were always looked up through their vars. While this is a > low-cost operation, it does not allow maximum performance. > > In 1.3, function calls are "compiled through" their vars. If function a calls > function c inside its body, there is no runtime lookup of the var c. However, > each function makes a (very low cost) check on entry to see if anything has > been recompiled. If so, the function is recompiled. This enables the dynamic > repl interaction that you would expect from a lisp, with great performance. > > When, as in your example, a var b refers to var a, there is no function call, > hence no hook point at which to make the check. If you want b to point to the > new a, redef b. >
Stu, This doesn't seem consistent with what Alyssa is reporting. She's getting a weird mix of both old 'a' and new 'a': > => (defn a > ([x] x) > ([x y] (+ (a x) (a y)))) > #'user/a > => (a 1 2) > 3 > => (def b a) > #'user/b > => (b 1 2) > 3 > => (defn a [x] > (- x)) > #'user/a > => (b 1 2) > -3 Let's call the original function assigned to 'a' a0 and the new one a1. After 'a' has been redefined to a1, 'b' still refers to a0. So the 2nd call to 'b' invokes a0 with two args (in fact, a1 only takes one arg now). But within a0 itself the references to 'a' are being resolved at runtime to a1 now, not as references to a0 as before. Are you saying that inside a0 Clojure detects that 'a' means something else now and recompiles a0 to point to a1? In any case, this behavior seems weird. Have all good days, David Sletten > Stu > >> Notice that when I redefined a, I only included one arity. If b were >> updated with the fn that a was redefined to, then (b 1 2) should have >> thrown an exception. Instead, it used the old definition of a but >> within that definition pointed to the new definition of a. This is >> internally inconsistent. >> >> I'm not proposing making all function definitions lexically bound. >> Yes, that would destroy interactive coding. >> >> But to be internally consistent, self-references should be lexical. >> >> In any case, I am using Github master and I thought I was using 1.2. >> 1.2 has self-references lexically bound, as David Sletten points out, >> which I agree is the correct behavior. But something has happened on >> 1.3 alpha that has changed that. I don't know if it's intentional or >> not. >> >> Thanks, >> Alyssa Kwan >> >> On Nov 16, 6:01 pm, David Nolen <dnolen.li...@gmail.com> wrote: >>> But that would destroy one of the most useful features Lisp has to offer, >>> interactive coding. >>> >>> Live coding would be impossible w/o this behavior as you would need to find >>> and update all callers. Yuk. >>> >>> David >>> >>> On Tue, Nov 16, 2010 at 5:26 PM, Alyssa Kwan <alyssa.c.k...@gmail.com>wrote: >>> >>> >>> >>>> I ran into this while working on making functions durable. Here's a >>>> contrived example: >>> >>>> => (defn a >>>> ([x] x) >>>> ([x y] (+ (a x) (a y)))) >>>> #'user/a >>> >>>> => (a 1 2) >>>> 3 >>> >>>> => (def b a) >>>> #'user/b >>> >>>> => (b 1 2) >>>> 3 >>> >>>> => (defn a [x] >>>> (- x)) >>>> #'user/a >>> >>>> => (b 1 2) >>>> -3 >>> >>>> Is this what people expect? I would think that the original >>>> definition of a, which is self-referencing, should point to itself no >>>> matter what it's named, not get resolved at invoke-time to see what >>>> the var is currently resolving to. >>> >>>> Thanks, >>>> Alyssa Kwan >>> >>>> -- >>>> 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<clojure%2bunsubscr...@googlegroups.com >>>> > >>>> For more options, visit this group at >>>> http://groups.google.com/group/clojure?hl=en >> >> -- >> 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 > > -- > 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 -- 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
