[braythwayt]

The equally interesting implication of your comment that "we don't get a stack trace from an ordinary loop" is that maybe we should have logging and introspection the behaviour of loops, and the fact that we have them for function invocation but not for loops is combination of a historical accident and a lack of interest in rethinking how languages are implemented.

[vilhelm_s]

And indeed, in Scheme (the language that originally made tail recursion famous) you can get stack traces from loops too! Well, at least in one Scheme implementation, MIT Scheme.

The MIT Scheme debugger has a notion of "reductions and subproblems" [1], which basically correspond to tail calls and non-tail calls. You can step "backwards" to the previous reduction, or "upwards" to the previous subproblem. In terms of other programming languages, that corresponds to going back to the previous loop iteration, or going up to the previous call frame.

Behind the scenes, this is implemented using a "ring-buffer or ring-buffers" [2], which stores the values of local variables for, e.g., the last 10 iterations through a loop. So if you step back further than that you will lose history and jump back to the start of the function call.

(The second link goes to the same blog as OP, I guess he has been writing a lot on this topic!)

[1] https://www.gnu.org/software/mit-scheme/documentation/stable... [2] http://funcall.blogspot.com/2009/05/you-knew-id-say-somethin...

[pkaye]

What information should be logged? And if the loop iterates for a million times, should we log it every time?

[Jtsummers]

It could be an option when debugging like adding a trace to your function calls. And the amount of tracing (how much is stored) could be configured.

Depending on the loop syntax, presumably you'd want to know (in the case of a for loop) what variables are initialized, what the test condition is and its result, and what is altered. But, in the case of C for loops as an example, this wouldn't be easy to automate since the user can always do something like:

  for(;;) {
    if(condition) break;
    // other logic
  }

In the best case (which would be the most data-ful case and hardest to use) you'd log all changes that occur within the loop. What you really want would be smaller, like detecting the break and the condition leading to it and watch that.

More realistically, you probably want to document your loop invariants with assertions which could be optionally recorded in your trace output.

[braythwayt]

I guess you're suggesting that adding a million lines to a log is excessive. But in my math, you can count lines like this: 1, 2, 3, ..., the-number-of-lines-that-fit-in-a-window, many.

Once you have more lines than fit in a window, you've already got "many" and now it's time to talk about tooling like searching logs.

A million lines of log feels like an excessive waste intuitively, but that's only because I was brought up on 8-bit computers with 16K of RAM. Now my watch has more power than probably all of the computers I owned in the 20th century put together, and a single image it displays might have more bits than a million lines of a log file.

---

I know this stuff isn't free, but we should at least consider the possibility that what we really need are proper and comprehensive logs/traces, and a "stack trace" is nothing more than an abbreviated execution trace that just happens to be relatively cheap to collect when something goes wrong.

[heavenlyblue]

how hard is it to log a million messages?