You propose a clever trick, but unfortunately it would require even more cleverness. What if foo, bar, and baz live in different libraries, and you reload one of the libraries as part of a dynamic update at runtime? How would the inline copies know they needed to update?
I am happy with explicit recur, given the alternatives. Cheers, Stuart > On Dec 20, 3:20 pm, verec <jeanfrancois.brouil...@googlemail.com> > wrote: >> Though I wonder how complicated it would be to "coalesce" any such >> set of mutually recursive functions into a single "JVM method" where >> such "local gotos" bytecodes exist and are documented -- that's what >> the Java "continue xyz" and "break xyt" translate to. > > Just expanding a little bit on this ... I don't recall that the JVM > allows > a single JVM method with more than one entry point, so the above > idea would be a non starter, except that there might be a way around > it: > > (defn foo [x] > ;; stuff > (bar x)) > > (defn bar [x] > ;; stuff > (baz x)) > > (defn baz [x] > ;; stuff > (bar x)) > > The trick would be to provide three different JVM methods, one for > each > of foo, bar and baz, all of which would contain *inline copies* of the > other > two's bytecodes and locally goto anywhere within that body of code. > > That would ensure proper TCO, without waiting ages for some potential > support in the JVM spec (and would work with 1.5!!) > > My 2p :-) > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---