Skip to content

Non-local variable

Treat a variable reference as non-local to a program unit when its binding is supplied by an enclosing or otherwise noncurrent scope, making scope resolution and captured-environment lifetime explicit.

Version
v2 · 2026-08-30 · History
Domain-specific #
2384
Origin domain
programming language semantics
Subdomain
scope and environment representation

Core Idea

A variable occurrence is non-local relative to a program unit when its binding is not declared in that unit's local environment; in the central lexical-scope case, the declaration is found in an enclosing textual scope rather than in the global environment or caller-selected environment. Name resolution walks the language's scope relation from the current environment toward enclosing environments until it finds the governing declaration, respecting shadowing. At runtime, nested procedures may reach the binding through static links, a display, or a closure environment; if the procedure escapes, captured storage must outlive the activation that originally created it.

Scope of Application

Non-local variable applies when the analyst can specify a program unit or expression, a variable occurrence within it, a hierarchy or chain of binding environments, and a language-specific scope rule and establish that locality is stated relative to one referencing unit, a governing declaration lies outside its local scope, the language's resolution rule selects that declaration, and runtime representation preserves the selected binding for as long as the reference can be evaluated. The entry describes programming-language binding semantics and implementation consequences, not a style recommendation or a claim that shared mutable non-local state is always desirable.

Clarity

A clear claim names the carrier, governing rule, assumptions, and recognition test. This matters because the term is relative to a particular program unit and different languages either include or exclude global variables, so examples must name both the reference point and binding rule.

Identity and measurement remain separate. Correctness is established through scope-resolution and lifetime semantics; performance comparisons must distinguish static-link traversal, displays, environment objects, and compiler optimizations.

Manages Complexity

The abstraction compresses lexically scoped nested functions, dynamically scoped languages, module globals, Python nonlocal declarations, Lua upvalues, static-chain and display implementations, closure conversion, and capture-by-value or by-reference policies into a stable carrier, rule, invariant, and failure boundary. It makes comparison tractable while retaining the variables that control validity.

Abstract Reasoning

  1. Type the carrier. Establish a program unit or expression, a variable occurrence within it, a hierarchy or chain of binding environments, and a language-specific scope rule and reject examples from a different problem. 2. Lock the rule. Express that locality is stated relative to one referencing unit, a governing declaration lies outside its local scope, the language's resolution rule selects that declaration, and runtime representation preserves the selected binding for as long as the reference can be evaluated independently of one notation or implementation.

Knowledge Transfer

Transfer within programming language semantics is strong when new cases preserve the same carrier, mechanism, and diagnostic. The move from In a lexically scoped language, an inner function that increments x declared in its enclosing outer function contains a non-local reference to that particular x. to A compiler represents a returned nested function as code plus an environment containing or pointing to its captured bindings, promoting an escaping mutable binding from an ordinary stack slot when necessary. demonstrates that continuity.

Relationships to Other Abstractions

Local relationship map for Non-local variableParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Non-local variableDOMAINPrime abstraction: Dependency — is a kind ofDependencyPRIME

Current abstraction Non-local variable Domain-specific

Parents (1) — more general patterns this builds on

  • Non-local variable is a kind of Dependency Prime

    The proposed strict upward parent is prime:dependency.

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

Non-local variable sits in a moderately populated region (52nd percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — Syntax, Rewriting & Declarative Form (41 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08