The issue here is not with b pointing to a. It's that b should point to b but doesn't. This *can't* be seen to be correct.
Thanks, Alyssa Kwan On Nov 17, 9:22 am, Stuart Halloway <stuart.hallo...@gmail.com> 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 > > > > > 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
