15 ms·

> On the other hand when things blow up, it is really nice to have a stack backtrace to help debug why it blew up. But a stack backtrace can't include stack fra

by steego 9y ago

> On the other hand when things blow up, it is really nice to have a stack backtrace to help debug why it blew up. But a stack backtrace can't include stack frames that were optimized away. Which makes it far harder to figure out why this call on this object turned into that call on that object. Is that really a concern? If you're writing a loop, do you expect your tools to show you a trace of every iteration in the loop? Of course not, because that would be silly. If you really want to trace each iteration, you can add your own tracing. I think of tail-recursion as parameterized gotos that are wonderfully constrained and are useful for describing state transformations in a predictable way. It's not a regular function call, so the stack trace is probably a very bad idea.

tuukkah 9y ago
Not all calls in tail position are recursive and when they are, they may be mutually recursive. This means it's not possible to detect and optimize recursive calls only.
bunderbunder 9y ago
I think it probably depends on how you think of the abstraction. Everyone readily thinks of loops, in the abstract, as "GOTO line X and do everything over again, but using all the state that has changed since the last time we were at line X." Ideally, you can think of recursion as nearly the same thing: "GOTO line X and do this stuff again, but using these very clearly stated changes to the data." If you think of recursion that way, then it's fairly self-evidently easier to reason about. In practice, though, I've met few developers who think that way and haven't spent significant time doing functional programming. I'm guessing it's because you need to spend a fair bit of time with both abstractions before you can really grok either of them. Without that, they're just kind of intimidating. Recursion more so, because everyone's taught from a young age to think imperatively.
sbmassey 9y ago
Tail recursion optimisation gets rid of all tail calls in functions, not just those that might lead to loops - you cannot in general detect those calls that might be loops. This can put a lot of holes in your stack trace.
- willtim 9y ago
  It's an optimisation. It can be turned off when debugging with stack traces. If you need stack traces in production code, you have too many partial functions.
  - Rusky 9y ago
    But you can't ever turn it off if you rely on it for loops, which defeats the whole point.
    - willtim 9y ago
      You can turn it off, you just can't process large data sets, as you'd run out of stack space. But who wants to debug with large data sets?
      - stormbrew 9y ago
        People who are debugging behaviour with large data sets perhaps? :P
        willtim 9y ago
        The runtime could allocate "stack frames" on the heap, for such cases.
jcelerier 9y ago
> If you're writing a loop, do you expect your tools to show you a trace of every iteration in the loop? Of course not, because that would be silly. If you really want to trace each iteration, you can add your own tracing. At least you can know at which iteration you are. If iterate over 12 elements and my loop counter is at 134753745, I can pinpoint what went wrong much more easily.
- cryptonector 9y ago
  No, that's only if you have a loop counter. And you can have a "loop" counter with function calls too.

by steego 9y ago

tuukkah 9y ago

Not all calls in tail position are recursive and when they are, they may be mutually recursive. This means it's not possible to detect and optimize recursive calls only.

bunderbunder 9y ago

I think it probably depends on how you think of the abstraction. Everyone readily thinks of loops, in the abstract, as "GOTO line X and do everything over again, but using all the state that has changed since the last time we were at line X." Ideally, you can think of recursion as nearly the same thing: "GOTO line X and do this stuff again, but using these very clearly stated changes to the data." If you think of recursion that way, then it's fairly self-evidently easier to reason about. In practice, though, I've met few developers who think that way and haven't spent significant time doing functional programming. I'm guessing it's because you need to spend a fair bit of time with both abstractions before you can really grok either of them. Without that, they're just kind of intimidating. Recursion more so, because everyone's taught from a young age to think imperatively.

sbmassey 9y ago

Tail recursion optimisation gets rid of all tail calls in functions, not just those that might lead to loops - you cannot in general detect those calls that might be loops. This can put a lot of holes in your stack trace.

willtim 9y ago
It's an optimisation. It can be turned off when debugging with stack traces. If you need stack traces in production code, you have too many partial functions.
- Rusky 9y ago
  But you can't ever turn it off if you rely on it for loops, which defeats the whole point.
  - willtim 9y ago
    You can turn it off, you just can't process large data sets, as you'd run out of stack space. But who wants to debug with large data sets?
    - stormbrew 9y ago
      People who are debugging behaviour with large data sets perhaps? :P
      - willtim 9y ago
        The runtime could allocate "stack frames" on the heap, for such cases.

jcelerier 9y ago

> If you're writing a loop, do you expect your tools to show you a trace of every iteration in the loop? Of course not, because that would be silly. If you really want to trace each iteration, you can add your own tracing. At least you can know at which iteration you are. If iterate over 12 elements and my loop counter is at 134753745, I can pinpoint what went wrong much more easily.

cryptonector 9y ago
No, that's only if you have a loop counter. And you can have a "loop" counter with function calls too.