Names and textual regions
Different parts of a program can use the same spelling without referring to the same variable. Lexical scope associates a use with bindings established by the surrounding textual regions. The language’s rules determine which enclosing binding is visible; a shared name does not imply one global storage location.
References: [1]
Shadowing an enclosing binding
An inner binding can shadow an enclosing binding of the same name. Uses outside that inner region still refer to their own environments. Scheme specifies binding regions, while Python defines local, enclosing-function, and global name resolution. The exact boundaries must be read from the language’s rules rather than guessed from indentation alone.
References: [2]
Definition context and calling context
Calling a function from a new location need not make it use the caller’s local variables. Lexical scope relates its free names to the definition environment, with closures supporting that relationship during execution. Dynamic scope is a different name-resolution model, not another name for dynamic typing or runtime type checking.
References: [1]
Scope and lifetime differ
Scope describes where a name can be used in a program; lifetime describes how long associated data remains available during execution. A returned closure may retain access after the surrounding function has finished. Distinguishing these questions clarifies encapsulation, shared state, and why storage need not disappear immediately upon a function’s return.
References: [2]