Talk:Tail recursion

message: my revision to the intro was because i thought the actual statement of what tail recursion really is had gotten a bit buried. Bgruber 04:52, 6 May 2006 (UTC)
thread_title: Intro

message: Previous tail recursion edit and Tail recursion differ only by <pre> being replaces with  tags, yet in firefox 1.0 <pre> yields 6 boxes and  yields 11 boxes! -- Dbroadwell 20:10, 17 Feb 2005 (UTC)
thread_title:  code and pre formatting in firefox 

message: The section about tr modulo cons currently has examples in C, which I'm afraid not everyone may be able to read; esp. an expression like malloc(sizeof(list)) may be very confusing. I've rewritten the first example in pseudocode (below), but I'm not sure how to express &(*p); are there conventions for working with pointers in pseudocode?
 function f(input : List) returns List
     if input = nil
         return nil
     else
         var n = new Link
         n.value = 1
         n.next  = f(input.next)
         return n
Qwertyus 13:08, 15 April 2006 (UTC)
thread_title:  C examples of tail recursion modulo cons 

message: I'm confused by:
    In some cases (such as filtering lists) and in some languages, full tail recursion may require a function that was previously purely functional to be written such that it mutates references stored in other variables.
I think this is trying to say either for efficiency reasons, some functions are re-written to use mutation, or if you have shared data, then operations like filter may want to mutate their inputs?  I'm unsure.  Either way, this is nothing specific to tail recursion.  --Ian Barland Not-just-yeti 14:31, 14 December 2006 (UTC)
thread_title:  bad example? 

message: IMHO The main point of distinction for tail recursion (as opposed to general recursion) is that it can be optimized. I know that Common Lisp and SCHEME optimize tail recursion intelligently. The wording of the intro suggests even tail recursion is always inefficient. I assume that is not intended. See Paradigms of Artificial Intelligence Programming by Peter Norvig page 63. 
Also IMHO, the functional equivalence and mutual transformability of recursion and iteration is true and important. But it is confusing to mention it in an intro to tail recursion. Can this be put somewhere else?
BTW: AI employers often ask applicants if they know about the significance to efficiency of tail recursion.  ClickStudent 14:35, 14 September 2007 (UTC)
replies: text: I do not think your assertion in your edit to the article that general recursion can be transformed into tail-recursion is correct. But I would love to be proved wrong. Do you have a reference? --MarSch 15:27, 14 September 2007 (UTC)
replies: text:  Apologies for my wording but you are absolutely correct (as far as I know). The  reason I left in the half truth is that this wording seemed to me to have a better chance of avoiding removal, given the apparent preference of the original writer for iteration universally. Sadly, truth is often politics. I have seen that in far too many wiki entries. Feel free to modify as you see fit. You obviously understand. BTW: This is my first wiki edit. It seemed presumptuous to start right out with modifying an intro. (afterthought: many could be replaced with tail recursion, but I don't want to do the Turing proof.) Apologies again. ClickStudent 13:33, 16 September 2007 (UTC)
replies: text: Please don't feel presumptuous about editing any part of any article. Taking action is encouraged (WP:BOLD).--MarSch 09:37, 17 September 2007 (UTC)

text:  Second afterthought...Any recursion CAN be transformed to a tail recursion. But you need to use another stack. Proofs about recursion generally get handled with the Pumping Lemma (see any computational theory textbook, e.g. Sipser). 'course, using another stack is probably cheating for purposes of our discussion. 17:35, 16 September 2007 (UTC)
replies: text: Right, the possibility of using an extra stack had slipped my mind. Anyway, general recursion is off-topic in this article, since this article is specifically about tail recursion. So even though your edit did not introduce any errors it does remove a simplified characterizaton of what tail recursion is. I will revert you for now, but don't let that discourage you from fixing any other issues that you perceive. --MarSch 09:37, 17 September 2007 (UTC)

text: One more thought. Perhaps the use of "iterative process" and "recursive process" (as also used in SICP) would clarify this article. --MarSch 09:41, 17 September 2007 (UTC)

text: OK, your points are well taken. I've given it a second try at simplification. (BTW: I'm reluctant to introduce the word "process" in an intro.) It seems to capture the essence of what tail recursion is good for, as far as I know. I hope you consider it to be accurate and concise. ClickStudent 11:44, 19 September 2007 (UTC)
replies: text: I've edited your version. I hope you're starting to like the intro better. --MarSch 15:03, 19 September 2007 (UTC)
replies: text: This version is extremely confusing. It sounds like tail recursion always returns immediately to the function that isn't part of the recursion. ClickStudent 20:21, 19 September 2007 (UTC)
thread_title:  Tail Recursion Distinctiveness Being Lost 

message: This article starts by talking about tail recursion and then gets lost in talking about tail call optimization.
A tail call is the general case where a procedure calls a procedure as its last action and does not need to do further processing of the result.  A tail recursion is a special case of a tail call where the procedure calls itself.  Tail recursion is much easier to optimize than general tail calls.  All it requires is that your target instruction set/language have an equivalent of jmp or goto.
In particular, that means that for the most common compiler targets -  C, virtually any machine code, and several virtual machines (JVM and CLR) - tail recursion can be done with little effort.  The compiler can just emit an imperative loop with a jmp/goto from the bottom of the procedure to the top (note, on the JVM Java does not do this optimization but Scala does).
The more general tail call case is what may require all the more advanced stuff this article talks about such as trampolining, garbage collected stack frames, etc.
Second, the article says that Scheme requires tail recursion optimization.  That's true, but not the real story.  Scheme (along with Haskell) requires full blown tail call optimization.  Of course, that implies tail recursion optimization as well because a tail recursive call is just a special case of a tail call.  —Preceding unsigned comment added by 149.63.92.58 (talk) 16:47, 17 October 2007 (UTC)
replies: text: The article is confusing, but tail call elimination (TCE) can be implemented through goto just as tail recursion implementation. The described devices are needed when you compile to C, which has no guaranteed TCE; I just clarified this in the article. Scala is a different case: given limitations of the JVM it can implement only tail-recursion optimization (because a jump in the JVM must be within a procedure). I also fixed the second point you mention. Blaisorblade (talk) 00:23, 23 July 2010 (UTC)
thread_title:  Article Confuses Tail Recursion with Tail Calls 

message: The second Scheme example should look similar to the first except for the change to accumulator style.  There is no need to use a lambda instead of the function definition short hand.  Also, why is there this addition of an assertion, especially if the contract states number -> number.
May I suggest:
(define (factorial n acc)
 (if (= n 0)
     acc
     (factorial (- n 1) (* n acc))))
If it is really necessary we could do
(define (factorial n)
  (factorial/acc n 1))
(define (factorial/acc n acc)
 (if (= n acc)
     acc
     (factorial (- n 1) (* n acc))))
129.10.116.251 (talk) 12:43, 10 June 2009 (UTC)
thread_title:  Second Scheme Example is Unnecessarily Complex 

message: The two articles are about the same subject, but the other is vastly inferior. However, the correct name is the one of the other article. In most cases general tail call optimization is as easy as tail recursion optimization (see the discussion in the freely available book "Programming Languages: Application and Interpretation").--Blaisorblade (talk) 01:24, 23 July 2010 (UTC)
replies: text: I agree these articles should be merged. —Tobias Bergemann (talk) 07:39, 23 July 2010 (UTC)
replies: text:  Merge performed, and I did some cleanup. Some more proof-reading is required probably, but I guess not today. --Blaisorblade (talk) 19:22, 9 October 2010 (UTC)
thread_title:  Should be merged with [[Tail call]]