Static vs Dynamic Scope

A variable occurrence inside a function body is either bound — declared as a parameter or local of some enclosing construct — or free, meaning it is not declared locally and must be resolved against some outer context. Scope is the policy that decides, for a free occurrence of a name, which binding of that name it denotes. This decision must be made either once, at the point the code is written (static scope), or repeatedly, at the point the code executes (dynamic scope). Under static scope (also called lexical scope), the binding for a free variable is the one declared in the smallest enclosing block, function, or module that textually contains the reference, searching outward through the nesting of the source code exactly as written — never through the chain of function calls. Because this search only depends on the program text, it can be performed once, by a compiler, before the program ever runs. The result is that a function's meaning is self-contained: you can determine what every name refers to by looking at the definition site and its lexical ancestors, regardless of who calls the function or from where. Under dynamic scope, the binding for a free variable is the most recent binding for that name that is still active on the call stack at the moment the reference is evaluated — i.e., the search walks backward through the chain of callers, not through the nesting of the source text. A function's meaning under dynamic scope depends on the entire history of calls that led to its invocation; the same function body can resolve a free name differently on two different calls, purely because the caller (or the caller's caller) happened to have declared a local variable with that name. This makes dynamic scope a form of implicit, name-based parameter passing — useful for things like ambient configuration, but dangerous for reasoning about correctness, because the meaning of an identifier is not determined by the code you are staring at. Almost every mainstream general-purpose language today — C, Java, Python, JavaScript, Scheme, ML, Rust — is statically scoped. Dynamic scope persists in specific corners: Unix shell variable and function lookup along certain paths, Emacs Lisp's "special variables," LaTeX macro expansion in some respects, and any ad hoc "context object" threaded implicitly through a call chain (thread-local variables and `contextvars`-style mechanisms are a controlled, opt-in form of dynamic scope layered on top of an otherwise lexically scoped language).

The cleanest way to see the difference is to look at the algorithm each discipline uses to resolve a free variable reference, and to notice that they consult different data structures: static scope consults the lexical nesting of the abstract syntax tree, dynamic scope consults the runtime call stack.

Static scope resolution. At compile time (or, for an interpreter, at closure-creation time), we walk outward through the lexical enclosing scopes of the point where the variable occurs in the source, stopping at the first scope that declares it. ``` // STATIC SCOPE RESOLUTION // Performed using the AST's lexical nesting, independent of any call. function resolveStatic(name, lexicalScopeChain): scope = lexicalScopeChain // innermost enclosing scope first while scope != null: if scope.declares(name): return scope.bindingFor(name) scope = scope.lexicalParent // determined by SOURCE TEXT nesting error "unbound variable: " + name // A closure captures its DEFINITION-TIME lexical scope chain. function makeClosure(functionBody, definitionScope): return Closure(code = functionBody, capturedScope = definitionScope) function callStatic(closure, args): newScope = extend(closure.capturedScope, bind(closure.params, args)) return evaluate(closure.code, newScope) // free vars resolve via capturedScope ``` The crucial line is `closure.capturedScope`: a closure remembers the scope chain that was lexically in effect where it was written, and every future call reuses that same chain to resolve free variables, no matter where the call originates.

Dynamic scope resolution. There is no notion of a captured definition-time scope. Instead, every function call pushes its local bindings onto a single global stack, and a free variable is resolved by searching that stack from the top (most recent call) downward. ``` // DYNAMIC SCOPE RESOLUTION // Performed against the RUNTIME CALL STACK, not the source text. globalBindingStack = [] // stack of activation records, most recent on top function resolveDynamic(name): for frame in globalBindingStack (top to bottom): if frame.declares(name): return frame.bindingFor(name) error "unbound variable: " + name function callDynamic(functionBody, params, args): frame = bind(params, args) push(globalBindingStack, frame) result = evaluate(functionBody) // free vars resolve via CURRENT stack pop(globalBindingStack) return result ``` Notice the symmetry and the key difference: both algorithms perform an outward/downward search through a chain of frames looking for the first declaration of `name`. Static scope's chain is fixed at closure-creation time and reflects source nesting; dynamic scope's chain changes on every call and reflects the current call history.

Two implementation strategies for dynamic scope are worth naming, because they trade off lookup cost against save/restore cost:

• Deep binding: pass the entire current binding stack (or a reference to it) along wherever a function value travels, so a later call resolves free variables against the stack as it stood at the moment the function value was captured, walked at call time. This is what our pseudocode does implicitly by having one global stack that grows/shrinks with calls.
• Shallow binding: maintain one mutable "current value" cell per variable name (like a global slot); on entering a scope that rebinds `x`, save the old value, overwrite the cell, and restore the old value on exit. Lookup is then O(1) (just read the cell) instead of a stack search, at the cost of save/restore bookkeeping on every call — this is exactly how Lisp's dynamic `let`/`special variable` binding and Unix shell dynamic scoping are typically implemented.

Lexical addressing, the standard compiler optimization for static scope, deserves a mention because it shows why static scope is fast: since the lexical nesting is fixed at compile time, a compiler can replace every variable reference with a pair `(depth, offset)` — how many enclosing scopes to skip, and which slot in that scope — computed once, ahead of time, so that at runtime resolution is a fixed number of pointer dereferences with no name comparison at all. ```

Time complexity of resolution.

• Static scope, naive environment chain: each free-variable lookup walks the chain of enclosing scopes, costing `O(d)` where `d` is the lexical nesting depth at that point, and each scope's own lookup (declares/bindingFor) costs `O(1)` if scopes are implemented as hash maps or `O(k)` for a linear scan of `k` locals. Since `d` and `k` are both bounded by the size of the program text — not the runtime call depth — this cost is bounded by a compile-time-known constant for any fixed program.
• Static scope with lexical addressing: because `d` and the offset are computed once at compile time, a lookup at runtime is exactly one fixed sequence of `depth` pointer hops plus one array index — `O(depth)` pointer chases with no comparisons, and `depth` is a compile-time constant per reference site, effectively `O(1)` amortized per access in generated code (some compilers flatten further into direct register/stack-slot allocation, making it truly O(1)).
• Dynamic scope, stack search: a lookup walks the call stack from the top until it finds a frame declaring the name, costing `O(c)` where `c` is the current call depth — a runtime quantity that can grow without any bound related to the program's static size (e.g., inside recursion). This is the fundamental asymmetry: static scope's cost is bounded by a static property of the program, dynamic scope's cost is bounded by a dynamic property of the execution.
• Dynamic scope, shallow binding: lookup is `O(1)` (direct cell read), but every call that shadows a variable pays `O(1)` save-and-restore overhead symmetric with entry/exit, so the total work across a computation is proportional to the number of (call, shadowed-variable) pairs, which is the same asymptotic work as deep binding, merely redistributed from lookup-time to call-time.

Space complexity. Static scope needs space proportional to the nesting structure of the source plus one environment frame per active closure invocation, exactly as much as the live data requires — this is the same frame structure used for ordinary stack-discipline function calls, augmented with saved parent pointers for closures that outlive their creating call. Dynamic scope needs one frame per active call on the global stack (same order as static scope's runtime frames), but no extra parent-pointer chain is needed since the entire call stack itself is the search structure.

Correctness argument — why static scope makes "read the code" a sound proof strategy. Define the lexical scope chain of a program point `p` as the finite sequence of enclosing block/function headers containing `p`, ordered innermost to outermost; this sequence is a syntactic property of the AST and is fixed for a given program text, independent of execution. Static scope resolution is precisely a deterministic function `resolveStatic : (Name, ASTNode) → Binding`, computable by a single traversal of the AST with no reference to any runtime state. Consequently, for a statically scoped language, the meaning of every variable reference is a pure function of the program text alone — this is exactly the property that lets a type checker, a linter, or a human reader determine "unbound variable" errors and shadowing behavior without running the program, and it is what justifies the standard closure-conversion transformation used in compiling The Functional Paradigm's higher-order functions: a closure can be compiled once into `(code pointer, captured environment)` and that pair is valid at every future call site, because the captured environment is exactly, and only, the lexical chain computed at definition time. Dynamic scope resolution is instead a function of program text and full call history: `resolveDynamic : (Name, CallStack) → Binding`. Two calls to syntactically identical code can resolve the same free name to different bindings whenever the call stacks differ, which means no local (AST-only) analysis can, in general, determine what a free variable refers to — in the worst case you must consider every possible caller, transitively, which is why dynamically scoped programs are notoriously hard to reason about modularly: a change to a caller's local variable name can silently change a callee's behavior, an effect sometimes called inadvertent capture. This is not a defect in any particular dynamic-scope implementation; it is a direct, provable consequence of making the resolution function depend on the call stack rather than on the AST.

Honest tradeoff. Dynamic scope is not "wrong" — it is a deliberate design choice when a program wants ambient, caller-supplied context without threading extra parameters explicitly (this is precisely what Unix shell environment variables, Lisp special variables such as `standard-output`, and thread-local/"implicit parameter" mechanisms in modern languages provide, in a controlled and clearly marked form). The tradeoff is: dynamic scope buys implicit, flexible context-passing at the cost of losing the "read the definition, know the meaning" guarantee that static scope provides, and losing compile-time detectability of unbound-variable errors in general (since whether a name is bound can depend on the call path actually taken at runtime).

Consider this pseudocode, written to make static and dynamic scope give different answers: ``` x = 10 function f(): return x + 1 function g(): x = 99 return f() print(g()) ``` Trace the resolution of the free variable `x` inside `f` under each discipline.

The two disciplines diverge at exactly the moment predicted by the theory above: `f`'s lexical parent is the top-level scope (because that is where `f` was written), but `f`'s nearest caller with an `x` binding is `g` (because that is who called it). Static scope follows the dashed line back through source nesting; dynamic scope follows the solid line back through the call stack — and in this example those two lines lead to different bindings of `x`, so the printed output differs: 11 under static scope, 100 under dynamic scope, from the identical program text. A second, shorter case shows the disciplines agreeing, to make clear the divergence is not automatic: if `g` never rebinds `x` at all, both disciplines find `x = 10` on every path, and both print `11` — the difference only surfaces precisely when a caller shadows a name that a callee's free variable also refers to.

The static/dynamic scope distinction crystallized out of the first wave of high-level, block-structured, and list-processing languages, when implementers first had to decide, concretely, how a free identifier inside a procedure should be resolved.

The funarg problem is worth naming explicitly because it is the historical fossil record of this entire article's argument: early Lisp implementers discovered, empirically, that returning a function from another function and calling it later gave surprising results under dynamic scope, because the free variables inside the returned function picked up whatever happened to be on the stack at the call site rather than what was in scope at the definition site. The fix — remembering the definition-time environment alongside the code, i.e., the closure — is exactly the `capturedScope` field in the static-scope pseudocode above, and it became one of the most consequential ideas in the history of programming languages.

Compilers and virtual machines. Static scope is what allows a compiler to perform lexical addressing, stack-frame layout, and register allocation entirely at compile time, producing the tight, offset-based variable access used by virtually every production compiler for C-family, ML-family, and JVM/CLR-targeted languages — dynamic scope would force every variable access to become a runtime stack search, which is untenable at the performance levels modern compilers target.

Shells and configuration DSLs. Unix shells resolve many variables (and in some shells, functions) dynamically along the call chain of sourced scripts, which is precisely why sourcing a script can silently change the behavior of functions defined elsewhere — a direct, everyday instance of the inadvertent-capture trap discussed above, and a reason shell scripting is notoriously fragile at scale.

Lisp dialects and "special" variables. Common Lisp and Emacs Lisp expose an explicit, marked dynamic-scope mechanism (`defvar`, "special" variables) precisely because certain use cases — rebinding `standard-output` for the duration of a call, or customizing a text editor's behavior contextually — genuinely want caller-supplied ambient context, and dynamic scope is the natural tool for exactly that need, so long as it is opt-in rather than the silent default.

Thread-local storage and context propagation. Modern systems (web frameworks propagating a request's tracing context, logging frameworks propagating a correlation ID) implement a controlled, structured form of dynamic scope — "the value visible depends on the current execution context" — precisely because passing such values as explicit parameters through every intervening function would be prohibitively invasive; these mechanisms are dynamic scope's legitimate modern descendants.

Closures and the functional paradigm. Every closure-based idiom — callbacks, iterators, currying, memoization wrappers — depends on static scope's guarantee that a function's free variables are pinned to its definition-time environment; this guarantee is the foundation the entire discussion of The Functional Paradigm builds on, and it interacts closely with Parameter Passing Mechanisms whenever a language must decide whether captured variables are copied by value or shared by reference.

Ask the tutor: Can you show how the same funarg-problem example would be compiled step by step into lexical-addressed bytecode under static scope?