3 ms·
> This is really just another complaint about lack of Tail-Call Optimization TCO needs to be supported by the runtime, but what I'm talking about only needs to
by bad_user 9y ago
> This is really just another complaint about lack of Tail-Call Optimization
TCO needs to be supported by the runtime, but what I'm talking about only needs to be supported by the Promise implementation, so in this case it's just a sloppy library we are talking about.
> When you create unbounded recursion, you leak memory
This is only true in weird universes, like that of JavaScript.
It's actually really easy to end up with a really long chain of tail recursive calls - for example when processing streams or when doing functional programming in general.
Having to explain why this is a huge problem is one reason for why I feel that JavaScript's ecosystem is so broken. In case you're wondering, given Promise's surprises, I actually think going for the callback hell is saner, because in such cases you just pass a callback around without surprises.
- sirclueless 9y agoTCO is classically a compiler/runtime optimization, but that's only because people didn't commonly implement fundamental control flow as libraries until relatively recently. Whether it is the runtime introspecting function calls to decide whether it can elide the current stack frame, or a futures library introspecting return values to decide whether the current future can delegate to the returned one, it's the same concept. As for "weird universes", it is typically only functional programming languages that guarantee TCO as part of their standard. Most programmers live in a world where they can't rely on their implementation to optimize tail-calls, which is to say they don't make unbounded recursive calls. If they do, they end up with an insidious form of non-portable code.
- bjpbakker 9y ago> Having to explain why this is a huge problem is one reason for why I feel that JavaScript's ecosystem is so broken This! Exactly this.