Thanks for the replies, that certainly clarified things! On 3 August 2010 13:39, Rich Hickey <richhic...@gmail.com> wrote:
> > > On Aug 3, 2:19 am, Daniel Kersten <dkers...@gmail.com> wrote: > > Can one not detect that a recursive call is a tail call and then > transform > > the AST so that its iterative instead - ie, not use the stack besides for > > initial setup of local variables (which then get reused in each recursive > > tail-call). Isn't this how its done in native compiled languages with > TCO? > > How is this different from generating bytecode for iterative loops in > > imperative languages, or from what recur does? Alternatively, why can't > the > > tail call be detected and converted into recur? I'm guessing that the > > problem is detecting tal calls - but why; speed of dynamic compilation? > > Something else? > > > > Obviously I'm missing something fundamental here - can somebody explain > to > > me what it is? > > > > When speaking about general TCO, we are not just talking about > recursive self-calls, but also tail calls to other functions. Full TCO > in the latter case is not possible on the JVM at present whilst > preserving Java calling conventions (i.e without interpreting or > inserting a trampoline etc). > Ah, this where my confusion was then. Self-calls aren't the problem at all, since they can be compiled how recur is, but tail-calls to other functions cannot be due to the JVM's calling conventions. I understand now, thanks for the explanation. > > While making self tail-calls into jumps would be easy (after all, > that's what recur does), doing so implicitly would create the wrong > expectations for those coming from, e.g. Scheme, which has full TCO. > So, instead we have an explicit recur construct. > Essentially it boils down to the difference between a mere > optimization and a semantic promise. Until I can make it a promise, I'd > rather not have partial TCO. To me, it is really only an optimization and I'm very much in the group who likes the explicit recur statement, since it conveys intent. Therefore I'd be happy with the partial optimization, though, honestly, not having it doesn't bother me at all. > Some people even prefer 'recur' to the redundant restatement of the > function name. In addition, recur can enforce tail-call position. > > Rich > > -- > 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 > -- Daniel Kersten. -- 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
