Two adjacent statements in an imperative tick loop are swapped and the simulation changes; what property makes order part of the meaning?

## Sequencing is the composition operator Every paradigm has a way of building bigger programs out of smaller ones. In the imperative family that way is the **sequence**: `A; B` means run `A`, then run `B` against the state `A` left. The statements do not hand each other values. They communicate by leaving marks in a store that the next statement reads. Once you see that, order stops looking like a formatting choice and starts looking like what it is — part of the program's meaning, at the same level as the statements themselves. This is not true everywhere. In a style where each step produces a value that the next step consumes, order is pinned only where one step genuinely needs another's result; anything else the evaluator may arrange as it likes. Imperative code hands that latitude back in exchange for cheap in-place update. ## The dependencies that pin a pair Whether two statements may be swapped is decided by which locations they touch and how. There are exactly three shapes of conflict, and each breaks in its own way: | Dependency | Shape | What a swap does | |---|---|---| | read-after-write | `A` writes `x`, `B` reads `x` | `B` now reads the older value | | write-after-write | both write `x` | the other one wins; the survivor changes | | write-after-read | `A` reads `x`, `B` writes `x` | `A` now reads the newer value | If none of the three holds, the two statements are **independent** and the swap is invisible in the result. That is the whole rule, and it is the same rule an optimising compiler applies before it reorders anything: a compiler is free to move independent statements, and only has to preserve what the dependencies imply. Two traps sit behind that neat table: - **Aliasing.** "The same location" is not the same as "the same name". If two names reach one record, a write through one is a write the other's dependency analysis has to account for. - **Effects outside the store.** Emitting a sound, appending to a log, sending a message — these are ordered by an observer you cannot see in the code, so two statements with no shared location may still not be interchangeable. ## A trace in the tick loop Take the two statements that resolve a hit on an entity: the write that subtracts damage, and the test that removes an entity whose health has dropped to zero or below. In the order **write, then test**, a lethal hit lands and is seen in the same tick: health goes to zero or below, the test reads that value, the entity is removed. In the order **test, then write**, the test reads the health from before this tick's damage. A lethal hit therefore leaves a removed-but-still-present entity for the remainder of the tick — it acts, it collides, it is drawn — and the removal happens on the following tick, when the test finally reads the reduced value. The bug is not that the entity never dies. It is that it dies **one tick late**, which is precisely the kind of defect that survives review: the text is identical, only the order differs, and the wrong version still terminates, still removes things, and looks right in every screenshot. ## When a swap really is safe Before moving a line, check all four: 1. Neither statement writes a location the other reads. 2. The two do not write the same location. 3. No alias makes two apparently different names reach one record. 4. Neither has an effect an outside observer orders — output, a message, a timestamp read. If all four hold, the swap cannot change the result, and the two statements can be grouped, extracted or parallelised. If any one fails, the order is load-bearing and deserves a comment saying so, because the next reader has no other way to know. ## Why this matters beyond tidiness Order-as-meaning is the property that makes imperative code cheap to write and expensive to reason about. You cannot read one statement and know what it does; you have to know what ran before it. Extracting a block into a subroutine can change behaviour if the block depended on state a caller set up. Two statements that looked independent become dependent the moment someone introduces an alias between them. And when the same sequence is run by two workers at once, the ordering that a single loop provided for free is simply not there any more. The answer an interviewer wants is the mechanism, not the observation. "Order matters" is the observation. "Statements compose by threading a shared store, so a statement's meaning depends on the state its predecessors left, and only the absence of a read/write dependency makes a swap safe" is the mechanism.