3 ms·
I'll believe destroying stacktrace information is a valid complaint when people start complaining that for loops destroy the entire history of previous values t
by chowells 2y ago
I'll believe destroying stacktrace information is a valid complaint when people start complaining that for loops destroy the entire history of previous values the loop variables have had. Tail recursion is equivalent to looping. People should stop complaining when it gives them the same information as looping.
- ameliaquining 2y agoI mean, if I were doing an ordinary non-recursive function call that just happened to be in tail position, and it got eliminated, and this caused me to not be able to get the full stack trace while debugging, I might be annoyed. In a couple languages I've seen proposals to solve this problem with a syntactic opt-in for tail call elimination, though I'm not sure whether any mainstream language has actually implemented this.
- chowells 2y agoLanguage designers could keep taking ideas from Haskell, and allow functions to opt in to appearing in stack traces. Give the programmer control, and all.
- SamLL 2y agoKotlin has a syntactic opt-in for tail call elimination (the "tailrec" modifier).
- michaelmrose 2y agohttps://clojuredocs.org/clojure.core/recur https://clojuredocs.org/clojure.core/recur
- roenxi 2y ago> I'll believe destroying stacktrace information is a valid complaint when people start complaining that for loops destroy the entire history of previous values the loop variables have had. That is a common criticism. You're referring to the functional programmers. They would typically argue that building up state based on transient loop variables is a mistake. The body of a loop ideally should be (at the time any stack trace gets thrown) a pure function of constant values and a range that is being iterated over while being preserved. That makes debugging easier.