tail-call-optimization

I am starting to learn ocaml, and am really appreciating the power of recursion in the language. However, one thing that I am worried about is stack overflows. If ocaml uses the stack for function calls, won't it eventually overflow the stack? For example, if I have the following function: let rec sum x = if x > 1 then f(x - 1) + x else x;; it must eventually cause a stack-overflow. If I was to do the equivalent thing in c++ (using recursion), I know that it would overflow. So my question is, is there built in safeguards to prevent functional languages from overflowing the stack? If not, are

See BlendingTable::create and BlendingTable::print . Both have the same form of tail recursion, but while create will be optimized as a loop, print will not and cause a stack overflow. Go down to see a fix, which I got from a hint from one of the gcc devs on my bug report of this problem. #include <cstdlib> #include <iostream> #include <memory> #include <array> #include <limits> class System { public: template<typename T, typename... Ts> static void print(const T& t, const Ts&... ts) { std::cout << t << std::flush; print(ts...); } static void print() {} template<typename... Ts> static void

We were experimenting with parallel collections in Scala and wanted to check whether the result was ordered. For that, I wrote a small function on the REPL to do that check on the very large List we were producing: def isOrdered(l:List[Int]):Boolean = { l match { case Nil => true case x::Nil => true case x::y::Nil => x>y case x::y::tail => x>y & isOrdered(tail) } } It fails with a stackOverflow (how appropriate for a question here!). I was expecting it to be tail-optimized. What's wrong? isOrdered is not the last call in your code, the & operator is. Try this instead: @scala.annotation.tailrec

Some VMs, most notably the JVM, are said to not support TCO. As a result, language like Clojure require the user to use loop recur instead. However, I can rewrite self-tail calls to use a loop. For example, here's a tail-call factorial: def factorial(x, accum): if x == 1: return accum else: return factorial(x - 1, accum * x) Here's a loop equivalent: def factorial(x, accum): while True: if x == 1: return accum else: x = x - 1 accum = accum * x This could be done by a compiler (and I've written macros that do this). For mutual recursion, you could simply inline the function you're calling. So,

Is there any workaround for Stack Overflow errors in recursive functions in Ruby? Say, for example, I have this block: def countUpTo(current, final) puts current return nil if current == final countUpTo(current+1, final) end if I call countUpTo(1, 10000) , I get an error: stack level too deep (SystemStackError) . It appears to break at 8187. Is there some function that I can call telling Ruby to ignore the size of stacks, or a way to increase the maximum stack size? Andrew Grimm If you're using YARV (the C based implementation of Ruby 1.9), you can tell the Ruby VM to turn tail call

The following program blows the stack: __find_first_occurrence :: (Eq b) => b -> [b] -> Int -> Int __find_first_occurrence e [] i = -1 __find_first_occurrence e (x:xs) i | e == x = i | otherwise = __find_first_occurrence e xs (i + 1) find_first_occurrence :: (Eq a) => a -> [a] -> Int find_first_occurrence elem list = __find_first_occurrence elem list 0 main = do let n = 1000000 let idx = find_first_occurrence n [1..n] putStrLn (show idx) Fails with Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize -RTS' to increase it. However, as far as I understand it, the possible recursive

Supose you have a recursive function like: Blah.prototype.add = function(n) { this.total += n; this.children.forEach(function(child) { child.add(n); }); }; Is the child.add() a tail call? If not can it be written so it is? Yes, it is a tail call: function(child) { child.add(n); // ^ tail } Yet nothing here is tail-recursive, because it's not a direct recursive call. Also this.children.forEach(…) is a tail call within the add method. However, the invocation of the callback within the native forEach method is probably not tail-call optimised (and all but the last one cannot be anyway). You can