A log loop computes the gap between each request and the previous one; why can no per-element stage do that directly?

Most loops over an access log are per-element in disguise: each line is examined on its own and folded into a result. The gap calculation is not one of them, and it is the cleanest example of the thing that resists a straight rewrite. ## Why the stage cannot see the neighbour A transformation stage is a function applied to one element. It receives that element and nothing about the traversal - no index, no memory of what came before, no handle on what comes next. The loop reached the previous line by subtracting one from its position. Remove the position and that reach disappears with it. This is what makes the loop **carry a dependency between iterations**: step *k* needs a value that only exists because step *k-1* happened. A per-element stage is by construction independent of every other element, so the two shapes do not line up. The same shape shows up all over a log summary: a rolling average of the last few durations, detecting a burst by comparing consecutive arrival times, numbering requests within a session, marking each line as a repeat of the previous one. ## Three honest routes 1. **Make the neighbour into data.** Build a stage that pairs each line with the one before it, then the gap is a plain per-element function over pairs. The dependency has not gone away; it has been paid for once, up front, in one named step. 2. **Thread the state explicitly.** Carry both the result so far and the previous element through the traversal as one value, so each step is handed everything it needs. This is the most faithful translation - it says out loud what the loop variable was doing silently - and it is also the least readable of the three when the state has more than one part. 3. **Keep the loop.** A dependency between consecutive steps is the case the loop form exists for. Restating it as stages is legitimate, but it is not automatically clearer, and a reviewer is entitled to ask what the rewrite bought. | What the loop used the position for | The explicit form | |---|---| | read the element before this one | pair each element with its predecessor | | keep a value from the last iteration | carry it in the accumulator alongside the result | | know how far along we are | pair each element with its position | ## The boundary that comes back Pairing n elements with their predecessors yields n-1 pairs, and the first line has no predecessor. That is a decision, not an accident: drop the first line, or supply an explicit starting value to compare it against. Either is defensible and the two give different answers, so it belongs in the code where a reader can see it. It is worth being precise about how this relates to the usual claim that transformation chains remove off-by-one errors. They remove the *arithmetic* - a start, a bound and an advance that must all be right on every path through the body. What survives here is a single boundary **decision** about the first element, made once and visible. That is a much smaller surface than an index, but it is not zero, and claiming otherwise is the overstatement an interviewer will push on. ## Why this question separates candidates A candidate who has only ever rewritten independent loops will assert that anything can be expressed as stages and reach for one. A candidate who has done it in production recognises the dependency on sight, names it, and then chooses - usually pairing when the neighbour relation is simple and local, and usually the loop when several values have to be carried at once. The tell is whether they mention the first element without being prompted.