Whilst starting to learn lisp, I\'ve come across the term tail-recursive. What does it mean exactly?
To understand some of the core differences between tail-call recursion and non-tail-call recursion we can explore the .NET implementations of these techniques.
Here is an article with some examples in C#, F#, and C++\CLI: Adventures in Tail Recursion in C#, F#, and C++\CLI.
C# does not optimize for tail-call recursion whereas F# does.
The differences of principle involve loops vs. Lambda calculus. C# is designed with loops in mind whereas F# is built from the principles of Lambda calculus. For a very good (and free) book on the principles of Lambda calculus, see Structure and Interpretation of Computer Programs, by Abelson, Sussman, and Sussman.
Regarding tail calls in F#, for a very good introductory article, see Detailed Introduction to Tail Calls in F#. Finally, here is an article that covers the difference between non-tail recursion and tail-call recursion (in F#): Tail-recursion vs. non-tail recursion in F sharp.
If you want to read about some of the design differences of tail-call recursion between C# and F#, see Generating Tail-Call Opcode in C# and F#.
If you care enough to want to know what conditions prevent the C# compiler from performing tail-call optimizations, see this article: JIT CLR tail-call conditions.
Using regular recursion, each recursive call pushes another entry onto the call stack. When the recursion is completed, the app then has to pop each entry off all the way back down.
With tail recursion, depending on language the compiler may be able to collapse the stack down to one entry, so you save stack space...A large recursive query can actually cause a stack overflow.
Basically Tail recursions are able to be optimized into iteration.
Tail recursion is the life you are living right now. You constantly recycle the same stack frame, over and over, because there's no reason or means to return to a "previous" frame. The past is over and done with so it can be discarded. You get one frame, forever moving into the future, until your process inevitably dies.
The analogy breaks down when you consider some processes might utilize additional frames but are still considered tail-recursive if the stack does not grow infinitely.
here is a Perl 5 version of the tailrecsum
function mentioned earlier.
sub tail_rec_sum($;$){
my( $x,$running_total ) = (@_,0);
return $running_total unless $x;
@_ = ($x-1,$running_total+$x);
goto &tail_rec_sum; # throw away current stack frame
}
There are two basic kinds of recursions: head recursion and tail recursion.
In head recursion, a function makes its recursive call and then performs some more calculations, maybe using the result of the recursive call, for example.
In a tail recursive function, all calculations happen first and the recursive call is the last thing that happens.
Taken from this super awesome post. Please consider reading it.
Recursion means a function calling itself. For example:
(define (un-ended name)
(un-ended 'me)
(print "How can I get here?"))
Tail-Recursion means the recursion that conclude the function:
(define (un-ended name)
(print "hello")
(un-ended 'me))
See, the last thing un-ended function (procedure, in Scheme jargon) does is to call itself. Another (more useful) example is:
(define (map lst op)
(define (helper done left)
(if (nil? left)
done
(helper (cons (op (car left))
done)
(cdr left))))
(reverse (helper '() lst)))
In the helper procedure, the LAST thing it does if the left is not nil is to call itself (AFTER cons something and cdr something). This is basically how you map a list.
The tail-recursion has a great advantage that the interpreter (or compiler, dependent on the language and vendor) can optimize it, and transform it into something equivalent to a while loop. As matter of fact, in Scheme tradition, most "for" and "while" loop is done in a tail-recursion manner (there is no for and while, as far as I know).