In case anyone is as confused as I was at first, agumonkey is referring to the fact that Functional Programming languages are capable of Tail Call Optimization, which allows functions to be composed without adding a new frame to the stack.

It's kind of interesting that TCO goes together with FP, because logically it makes at least as much sense for OOP, as Guy Steele pointed out at http://www.eighty-twenty.org/2011/10/01/oo-tail-calls.html

The concept of combining many values to get another value of the same type is the heart of FP - function composition is just the most prominent example of it. That definition of IntSet is effectively a cons list, a very FP-oriented data structure. It's not an example of OOP needing tail calls because it's not an example of OOP style (at least, if we believe that's something disjoint from functional style) at all.

I don't consider OO to be disjoint from functional; the first OO language was the untyped lambda calculus (as William Cook's said). In the taxonomy at http://www.paulgraham.com/reesoo.html we're looking at 2. protection and 6. "all you can do (with an object) is send a message", like how all you can do with a function is call it.

I don't agree that FP owns compositionality. In the 80s and 90s I used to have to argue for the value of functional programming; nowadays the closeminded attitudes come more from the "other side", and from one POV that's heartening progress, but from another it's silly to be running culture wars around technical ideas.

I've never seen an OO article / book that managed to demonstrate composition even at 1% that the average Haskell book does. I'm trying not to take sides too much, but I grew up in OO-land, left and keep getting mesmerized by what the FP guys have been doing. Most recently monadic thinking (I know, monads) but bind as an abstract composition operator is maddeningly beautiful. Although I've heard that Monads themselve don't compose ~_~;

It's great how Haskell and friends keep spreading, isn't it? Here is an OO book I like: http://www.erights.org/talks/thesis/

Thanks for decyphering cryptic acronyms. To add to this, Tail call makes you realize that logically, function call != pushing on stack. Then I started looking at how people handled recursion on hardware before stack support was added. And how people managed the stack explicitely themselves. (can't find that article again sadly).

Uh, lots of languages are capable of tail call optimizations, return value optimizations. Things are not pushed to stack unless optimizations are impossible I believe