1. 10
  1.  

  2. 2

    So… the article is a set of quotes from (some pretty well known) people who dislike tail call optimization because it allegedly makes it harder to debug code, since stack frames are being dropped? Maybe this is supposed to be a satirical stab at those people’s stance on the matter, but I actually doubt this is a relevant issue anyway:

    First of all, you can simply drop TCO on the debug-builds of your platform. Of course, this assumes a correct implementation of the optimization technique itself, which might itself become harder to debug, but this simply isn’t a concert for a user who “inadvertently wrote something recursive”.

    Then, it is possible to implement TCO in a more debugging-friendly way, I’d imagine. If the compiler simply replaces the values on the stack/in registers that were passed as the arguments to a recursive function call, one can hook into that code and modify the stack trace that would be dumped later. This should be applicable to interpreted languages as well, with some transformations.

    I’m not an expert, but this whole argument seems like a strawman to me.

    1. 2

      First of all, you can simply drop TCO on the debug-builds of your platform. Of course, this assumes a correct implementation of the optimization technique itself, which might itself become harder to debug, but this simply isn’t a concert for a user who “inadvertently wrote something recursive”.

      In languages that rely on TCO heavily for logic, this sounds like an easy way to implement debug-only bugs ( you blow your stack easily).

      I agree with you though that this should be fixable by creating TCO-aware debug info.

      1. 2

        In languages that rely on TCO heavily for logic, this sounds like an easy way to implement debug-only bugs ( you blow your stack easily).

        Yes, that issue might come up, but it’s not what the article addresses. However, I’m unaware of languages relying on TCO for logic, as it is - as far as I know - transparently implemented in most (all?) cases. That is to say, in what context does it even make sense to make the programmer deliberately aware of the presence of TCO?

        1. 1

          In an ML-like language, an iterative loop might look like

          fun factorial n acc = if n < 2 then acc else factorial (n-1) (acc*n)
          

          Tail recursion is the difference between this working fine or blowing out the stack for large integers. In a language that guarantees proper tail calls, turning it off will break a lot of code.

          1. 1

            Yes, that issue might come up, but it’s not what the article addresses.

            Sure, as I wrote, I don’t buy into the arguments of the article, but also not into the simplicity of the solution.

            However, I’m unaware of languages relying on TCO for logic, as it is - as far as I know - transparently implemented in most (all?) cases. That is to say, in what context does it even make sense to make the programmer deliberately aware of the presence of TCO?

            Erlang uses TCO heavily. Many processes are implemented as:

            • spawn function f
              • receive
              • work
              • call f recursively
            1. 2

              Erlang uses TCO heavily. Many processes are implemented as: * spawn function f * receive * work * call f recursively

              Exactly, but how does the programmer need to be aware of TCO being used if thinking in terms of recursion is perfectly possible with a reasonable debugging setup?

              1. 2

                They don’t. Probably in the case above, retaining previous states of the function would also be terribly confusing when debugging in the common case.

                I think we’re on the same page, but talking a little past each other :).

                1. 1

                  It’s quite possible you could run out of memory.

        2. 2

          WebKit solved this. People still echo about debugging and others myths to support their ulterior motive of easier binary compatibility with C.

          1. 1

            ShadowChicken looks interesting! I hadn’t seen it before.