Raymond Toy wrote: Yes and no. If function calls were faster, the tail-recursive functions would be faster with or without tail recurion optimisation. OTOH, they would still have O(n) memory complexity, which would rule out their use for processing long lists. The point about tail recursion is that it is equivalent to iteration. You should be able to convert a tail-recursive function into a loop. So certain forms of recursion are just `syntactic sugar' on top of iteration. If writing a function using tail-recursion is slower than using the equivalent iterative form, then the optimisation isn't complete. However, provided that it's `close enough', people can write code in its natural form, knowing that any performance hit is a) proportionate, rather than affecting the asymptotic time/space complexity, and b) likely to diminish over time. Well, from a theoretical viewpoint, without optimised tail-recursion, you can't write general-purpose list-scanning functions (mapcar, memq, ...) using tail-recursion, because eventually you'll get a case where they run out of stack, whereas (explicitly) iterative versions wouldn't. In a sense, you end up with the worst of both worlds. People who don't like functional languages don't like elisp because it looks like a functional language. People who do like functional languages don't like elisp because you can't use it like any other functional language. -- Glynn Clements <glynn(a)sensei.co.uk&gt;