2010/11/17 Laurent PETIT <laurent.pe...@gmail.com> > > > 2010/11/17 Stuart Halloway <stuart.hallo...@gmail.com> > > 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. > > > Wait, what ?? >
I mean, is this new stuff since the "state of the art" of the week where the conj occured ? (do you have an idea of where in the irc logs one could "follow history" on this ?) > > >> 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> >> <clojure%2bunsubscr...@googlegroups.com<clojure%252bunsubscr...@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<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<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
