[MrBuddyCasino]

Pretty good arguments in there:

- TCO only addresses recursion that can easily be replaced by a loop

- loosing stack frames makes debugging harder

- its not just an optimization, as soon as code depends on it to not blow the stack its a required feature for all implementations

- functional languages with no side effects need recursion, everyone else really doesn't

Personally, I think TCO is bad in a similar way as async functions. It is an exception from the general mental model of how function calls work, makes tooling much more complex and the alternative is just writing a loop, which I know is beneath the average Lambda The Ultimate subscriber, but its just how some people earn their money.

[dragonwriter]

> TCO only addresses recursion that can easily be replaced by a loop

This is simply false. Specialized tail recursion optimization, which I've seen a few places, approximately does that, but generally TCO covers a lot of things that aren't easily replaceable with for loops.

> its not just an optimization, as soon as code depends on it to not blow the stack its a required feature for all implementations

True, though that's an argument for it, not against it.

> loosing stack frames makes debugging harder

This is a weird argument to include with the for-loop thing, since the stack frames “lost” would never exist in the for-loop form for the case where there is a straightforward equivalence. In general, I find that this is mildly true (it sometimes make spotting the source of an error from the dump an an unhandled exception harder, but doesn't really make any debugging that involves more than that harder).

> functional languages with no side effects need recursion, everyone else really doesn't

Regardless of whether the language has side effects available, functional code without side effects is easier to analyze and assure important properties of, and it's beneficial to be able to leverage that even if you have a language that allows side effects.

[kreetx]

As far as I understand, TCO (or PTC?) gives you "structured goto", i.e something that would be a pain to write as a loop, won't either mess up the state/scope, but still achieve that "loop speed" without stressing the stack.

[vgatherps]

Being able to guarantee tail calls is a useful optimization in far more cases than code replaceable by loops. I’ve used it myself where dispatch targets themselves are dynamic (so can’t be trivially made into a loop) for significant performance gains.

Some other folks who’ve done the same thing (and can post publicly) for code that’s not just “must recurse because loops are for lowly imperative serfs”:

* https://blog.reverberate.org/2021/04/21/musttail-efficient-i...

* http://lua-users.org/lists/lua-l/2011-02/msg00742.html

* https://cantortrading.fi/rust_decimal_str/

Now does JavaScript really need/care about any of this? Probably not.

[MrBuddyCasino]

Interesting use case, didn't occur to me that tail calls can also just be a performance optimisation technique to help out the compiler and branch predictor. I assumed hot loops could be implemented just as well using GOTOs, but maybe not?

[chriswarbo]

> I assumed hot loops could be implemented just as well using GOTOs, but maybe not?

Tail calls are GOTOs; that's the whole argument https://apps.dtic.mil/sti/citations/ADA030751

[blagie]

Everything can be implemented using IF statements and GOTOs. That's how early processors worked, and Turing completeness and all. We don't _really_ need function calls, while loops, or for loops either.

That doesn't mean it's a good idea.

[HALtheWise]

In the particular linked case of protobuf parsing, a loop with goto's doesn't produce very well optimized code because of specific internal details about how modern C compilers do optimizations. You could certainly imagine a compiler that can fully optimize a go-to heavy program, in which case the code cleanliness argument would be the only reason.

[vgatherps]

Tail calls are basically GOTOs, yeah. The bring a HUGE benefit of very clearly defining state flow between gotos which makes the compiler's job super easy.

[teakettle42]

> TCO only addresses recursion that can easily be replaced by a loop

This is fundamentally false.

TCO addresses recursion that is implemented through the arbitrarily complex composition of functions, enabling one to define arbitrarily complex loop constructs through function composition.

There are many such interesting compositions that cannot be “unrolled” into a single high-level imperative for loop without essentially having to rewrite the code of all the functions being composed, including code that controls looping in interesting ways (e.g. automatically terminating on error, collecting all errors, parallelizing execution, etc.)

> It is an exception from the general mental model of how function calls work

It’s not, though — unless you have an incorrect mental model of how function calls work.

When calling a function, the return address is first pushed on the stack (or on some architectures, stored in a link register).

The target function returns from execution by popping the return address from the stack (or reading it from a link register), and jumping to that address.

When calling a function, if the call is in a tail position, the calling function can provide it’s original return address, and then jump to the target function it’s calling.

That’s how functions actually work. That’s the mental model.

> makes tooling much more complex

What significant complexity does TCO add to tooling, exactly?

> the alternative is just writing a loop

That’s simply not true. See first paragraph above.

[Spivak]

> There are many such interesting compositions that cannot be “unrolled”.

You're arguing semantics, sure, you cannot mechanically transform code which relies on TCO into a loop. That is not the same as the parents point that TCO functions are isomorphic to loops. In a language without TCO you wouldn't ever find yourself in mess of composition of functions.

[teakettle42]

> You're arguing semantics, sure, you cannot mechanically transform code which relies on TCO into a loop.

TCO is how you mechanically transform recursive code into a loop.

> That is not the same as the parents point that TCO functions are isomorphic to loops.

That’s the same as claiming that manually copy-pasting the contents of functions into your code is isomorphic to calling those functions.

> In a language without TCO you wouldn't ever find yourself in mess of composition of functions.

Yes, that’s the point. There’s an entire class of useful constructions that cannot be implemented without TCO.

[hajile]

This argument happens enough that it should be considered its own fallacy "appeal to the turing tarpit".

By this logic, we should still be using GOTO because if we were, you'd never need to use loops.

Proper tail calls exist because they make the logic of a lot of things easier and more simple to follow.

[soegaard]

Principles of functional programs also apply when computing with objects.

"Object-Oriented Programming in languages that don’t require tail-call optimizations makes no sense."

- Matthias Felleisen

Why? See part 3 of this presentation from ECOOP 2004.

https://web.archive.org/web/20180324164849/http://www.ccs.ne...

Another quote: > One common misunderstanding about TCO is due to the word 'optimization'. It is indeed a space optimization (don't use more space than goto, as Guy said in the 1970s) but a language should implement TCO in support of PROPER DESIGN. To wit, go through the OO design pattern books and inspect all the little patterns. Pick some -- say interpreter or composite -- and design your Java program accordingly. Then run a stress test and weep. Java blows up even if all the method calls are tail-recursive because it doesn't support TCO. Now do the same in PLT Scheme's class system and smile. It works -- for all inputs.

[6gvONxR4sf7o]

Replacing a stack of function calls with a loop may be the same in terms of what happens, but it’s the like inlining code in general. Sometimes packaging it up makes it cleaner and more reusable and testable, relative to inlining it (or sticking it in a for loop).