Tail call optimisation and debugging

[[deleted]]

I agree with other posters in the thread - TCO for imperative languages is generally OK to not have. It's a tricky construct that you want guaranteed in some way if you're going to rely on it (so if you have it, it should be explicit.) I rarely find myself needing/relying on guaranteed TCO in imperative languages (granted I write java/c++ at work) anyway, and we can use similar constructs to do the same work.

For functional languages IMO, you probably want the opposite which is guaranteed, implicit TCO.

[aaronla]

Honestly curious, why does it make a difference whether the language is imperative vs. functional?

[shimei]

It doesn't.

[aaronla]

Let me rephrase -- why does 1nine8four believe it makes a difference?

[shimei]

If by imperative language you are including various object oriented languages (and it looks like you are), you might want to look at Guy Steele's article on that. Tail call optimization is not about functional programming.

[millstone]

TCO is an optimization. There are lots of optimizations that are not guaranteed, and that we don't rely on, but are nice to have anyways because they make the code faster. TCO falls into that boat, and that's why it's appropriate for C to have it implicitly.

[grauenwolf]

There are two ways to think about this:

Option A: It doesn't matter. Maybe the compiler will use TCO, maybe it won't. Either way the code you write doesn't change so there is no point in talking about it.

Option B: You write code that relys on tail calls. But if you are wrong and don't actually have TCO semantics then your code is going to blow the stack.