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 > 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
