Why does a resolver collect a scope's declarations before it resolves the references inside that scope?

## The failure a single walk produces Imagine resolving a scope in one pass, left to right, inserting each declaration as you reach it and resolving each reference against whatever is in the table at that moment. That works for the common case of declare-then-use, and it fails immediately for two definitions that refer to each other: ```pseudocode step validate(item): if item.needs_expansion: return expand(item) // names a step declared below return item step expand(item): return validate(unpack(item)) // names the step declared above ``` Whichever definition is written first, its body names something the table does not yet hold. No ordering of the text fixes this — the cycle is in the program, not in the layout. The same problem appears in gentler form whenever a script's author writes the entry point at the top and the helpers underneath, which is how most people prefer to read code. ## Split the scope into collect and resolve The standard structure is two sub-passes over the same scope: 1. **Collect.** Walk only the declarations of the scope. Insert an entry for each into that scope's table, recording kind, declaration position, and the declared type if the syntax states one. If the name is already present in *this* table, report a duplicate declaration — the parser accepted both because the shape is legal, so this sub-pass is the first thing in the pipeline that can notice. 2. **Resolve.** Walk the statements. For each reference, run the outward scope-chain lookup and record the binding on the tree. Descend into a nested block by pushing a new table and repeating both sub-passes for it. The cost is a second traversal of one scope's nodes; the benefit is that resolution no longer depends on the order in which a human chose to write the definitions. ## Order-independent versus declare-before-use It would be an overstatement to say every scope works this way. Languages differ, and the useful way to hold the distinction is per scope kind: | Scope kind | Typical rule | Why | |---|---|---| | Top-level or named-step scope | Order-independent: collect all, then resolve | Mutual recursion must work; authors reorder definitions freely | | Block or loop body | Declare-before-use as well as collected | A reference above the declaration would read a slot that has no value yet | | Parameter list | Collected before the body is resolved | The body must see every parameter regardless of position | Where declare-before-use applies, the resolver does **not** abandon collection. It still collects, because collecting is what lets it produce the good diagnostic: a reference to a name that exists further down the same block can be reported as *used before it is declared*, pointing at both positions, instead of the misleading *no such name* that a single walk would emit. The check is a comparison of two recorded positions, not the absence of an entry. ## What the collected table buys the rest of the pipeline A complete table per scope is also what makes the type checks tractable. Checking the body of one definition against another requires the other's signature; if signatures were only discovered by reaching them, the checker would inherit the same ordering problem one level up. Collecting declarations first gives every later pass a stable question to ask — *what is this name declared as?* — that is answerable at any point in the tree. There is one honest wrinkle. Collection can record a **declared** type immediately only when the syntax states one. Where a declaration's type is meant to be worked out from its initialiser, the entry is created during collection with its type still unknown and filled in later, and a genuine cycle among such declarations (each one's type depending on the other's) is a case the language has to reject explicitly rather than loop on. That is why order-independence is usually granted generously to definitions whose signatures are written out, and more cautiously to declarations whose types are implied. ## How to say this in an interview The compact version is three sentences: a reference may legitimately precede its declaration, so the resolver populates a scope's table before it resolves the scope's references; that makes mutual recursion work and makes definition order a matter of taste rather than of correctness; and where a language still demands declare-before-use, the collected entry is what turns a confusing *unknown name* into a precise *used before declared* pointing at both lines.