Scope (computer science)

In computer programming, the scope of a name binding—an association of a name to an entity, such as a variable—is the region of a computer program where the binding is valid: where the name can be used to refer to the entity. Such a region is referred to as a . In other parts of the program the name may refer to a different entity, or to nothing at all.
The scope of a binding is also known as the visibility of an entity, particularly in older or more technical literature—this is from the perspective of the referenced entity, not the referencing name. A scope is a part of a program that is or can be the scope for a set of bindings—a precise definition is tricky, but in casual use and in practice largely corresponds to a block, a function, or a file, depending on language and type of entity. The term "scope" is also used to refer to the set of all entities that are visible or names that are valid within a portion of the program or at a given point in a program, which is more correctly referred to as context or environment.
Strictly speaking and in practice for most programming languages, "part of a program" refers to "portion of the source code ", and is known as lexical scope. In some languages, however, "part of a program" refers to "portion of run time ", and is known as dynamic scope. Both of these terms are somewhat misleading—they misuse technical terms, as discussed in the definition—but the distinction itself is accurate and precise, and these are the standard respective terms. Lexical scope is the main focus of this article, with dynamic scope understood by contrast with lexical scope.
In most cases, name resolution based on lexical scope is relatively straightforward to use and to implement, as in use one can read backwards in the source code to determine to which entity a name refers, and in implementation one can maintain a list of names and contexts when compiling or interpreting a program. Difficulties arise in name masking, forward declarations, and hoisting, while considerably subtler ones arise with non-local variables, particularly in closures.

Definition

The strict definition of the "scope" of a name is unambiguous—it is "the portion of source code in which a binding of a name with an entity applies"—and is virtually unchanged from its 1960 definition in the specification of ALGOL 60. Representative language specifications follow.
;ALGOL 60
;C
;Go
Most commonly "scope" refers to when a given name can refer to a given variable—when a declaration has effect—but can also apply to other entities, such as functions, types, classes, labels, constants, and enumerations.

Lexical scope vs. dynamic scope

A fundamental distinction in scoping is what "part of a program" means. In languages with lexical scope, name resolution depends on the location in the source code and the lexical context, which is defined by where the named variable or function is defined. In contrast, in languages with dynamic scope the name resolution depends upon the program state when the name is encountered which is determined by the execution context or calling context. In practice, with lexical scope a variable's definition is resolved by searching its containing block or function, then if that fails searching the outer containing block, and so on, whereas with dynamic scope the calling function is searched, then the function which called that calling function, and so on, progressing up the call stack. Of course, in both rules, we first look for a local definition of a variable.
Most modern languages use lexical scoping for variables and functions, though dynamic scoping is used in some languages, notably some dialects of Lisp, some "scripting" languages, and some template languages. Perl 5 offers both lexical and dynamic scoping. Even in lexically scoped languages, scope for closures can be confusing to the uninitiated, as these depend on the lexical context where the closure is defined, not where it is called.
Lexical resolution can be determined at compile time, and is also known as early binding, while dynamic resolution can in general only be determined at run time, and thus is known as late binding.

Related concepts

In object-oriented programming, dynamic dispatch selects an object method at runtime, though whether the actual name binding is done at compile time or run time depends on the language. De facto dynamic scoping is common in macro languages, which do not directly do name resolution, but instead expand in place.
Some programming frameworks like AngularJS use the term "scope" to mean something entirely different than how it is used in this article. In those frameworks the scope is just an object of the programming language that they use that is used in certain ways by the framework to emulate dynamic scope in a language that uses lexical scope for its variables. Those AngularJS scopes can themselves be in scope or out of scope in any given part of the program, following the usual rules of variable scope of the language like any other object, and using their own inheritance and transclusion rules. In the context of AngularJS, sometimes the term "$scope" is used to avoid confusion, but using the dollar sign in variable names is often discouraged by the style guides.

Use

Scope is an important component of name resolution, which is in turn fundamental to language semantics. Name resolution varies between programming languages, and within a programming language, varies by type of entity; the rules for scope are called scope rules or scoping rules. Together with namespaces, scoping rules are crucial in modular programming, so a change in one part of the program does not break an unrelated part.

Overview

When discussing scope, there are three basic concepts: scope, extent, and context. "Scope" and "context" in particular are frequently confused: scope is a property of an identifier, and is fixed, while context is a property of a program, which varies by position. More precisely, context is a property of a position in the program, either a position in the source code or a point during run time. Execution context consists of lexical context plus additional runtime state such as the call stack. Thus, when the execution point of a program is in a variable name's scope, the "variable is in context", and when the execution point "exits a variable 's scope", such as by returning from a function, "the variable goes out of context". Narrowly speaking, during execution a program enters and exits various scopes, and at a point in execution identifiers are "in context" or "not in context", hence identifiers "come into context" or "go out of context" as the program enters or exits the scope—however in practice usage is much looser.
Scope is a source-code level concept, and a property of identifiers, particularly variable or function names—identifiers in the source code are references to entities in the program—and is part of the behavior of a compiler or interpreter of a language. As such, issues of scope are similar to pointers, which are a type of reference used in programs more generally. Using the value of a variable when the name is in context but the variable is uninitialized is analogous to dereferencing a wild pointer, as it is undefined. However, as variables are not destroyed until they go out of context, the analog of a dangling pointer does not exist.
For entities such as variables, scope is a subset of lifetime —a name can only refer to a variable that exists, but variables that exist are not necessarily visible: a variable may exist but be inaccessible, or accessible but not via the given name, in which case it is out of context. In other cases "lifetime" is irrelevant—a label has lifetime identical with the program, but may be in or out of context at a given point in the program, and likewise for static variables—a static global variable is in context for the entire program, while a static local variable is only in context within a function or other local context, but both have lifetime of the entire run of the program.
Determining which entity an identifier refers to is known as name resolution or name binding, and varies between languages. Given an identifier, the language checks all entities that are in context for matches; in case of ambiguity, the name resolution rules are used to distinguish them. Most frequently, name resolution relies on an "inner-to-outer" rule, such as the Python LEGB rule: names implicitly resolves to the narrowest relevant context. In some cases name resolution can be explicitly specified, such as by the global and nonlocal keywords in Python; in other cases the default rules cannot be overridden.
When two identical identifiers are in context at the same time, referring to different entities, one says that name masking is occurring, where the higher-priority name is "masking" the lower-priority name. At the level of variables, this is known as variable shadowing. Due to the potential for logic errors from masking, some languages disallow or discourage masking, raising an error or warning at compile time or run time.
Various programming languages have various different scoping rules for different kinds of declarations and identifiers. Such scoping rules have a large effect on language semantics and, consequently, on the behavior and correctness of programs. In languages like C++, accessing an unbound variable does not have well-defined semantics and may result in undefined behavior, similar to referring to a dangling pointer; and declarations or identifiers used outside their scope will generate syntax errors.
Scopes are frequently tied to other language constructs and determined implicitly, but many languages also offer constructs specifically for controlling scope.

Levels of scope

Scope can vary from as little as a single expression to as much as the entire program, with many possible gradations in between. The simplest scoping rule is global scope—all entities are visible throughout the entire program. The most basic modular scoping rule is two-level scoping, with a global scope anywhere in the program, and local scope within a function. More sophisticated modular programming allows a separate module scope, where names are visible within the module but not visible outside it. Within a function, some languages, such as C, allow block scope to restrict scope to a subset of a function; others, notably functional languages, allow expression scope, to restrict scope to a single expression. Other scopes include file scope, which functions similarly to module scope, and block scope outside of functions.
A subtle issue is exactly when a scope begins and ends. In some languages, such as in C, a scope starts at declaration, and thus different names declared within a given block can have different scopes. This requires declaring functions before use, though not necessarily defining them, and requires forward declaration in some cases, notably for mutual recursion. In other languages, such as JavaScript or Python, a name's scope begins at the start of the relevant block, regardless of where it is defined, and all names within a given block have the same scope; in JavaScript this is known as variable hoisting. However, when the name is bound to a value varies, and behavior of in-context names that have undefined value differs: in Python use of undefined variables yields a runtime error, while in JavaScript undefined variables are usable, but function declarations are also hoisted to the top of the containing function and usable throughout the function.

Expression scope

Many languages, especially functional languages, offer a feature called let-expressions, which allow a declaration's scope to be a single expression. This is convenient if, for example, an intermediate value is needed for a computation. For example, in Standard ML, if f returns 12, then let val x = f in x * x end is an expression that evaluates to 144, using a temporary variable named x to avoid calling f twice. Some languages with block scope approximate this functionality by offering syntax for a block to be embedded into an expression; for example, the aforementioned Standard ML expression could be written in Perl as do , or in GNU C as .
In Python, auxiliary variables in generator expressions and list comprehensions have expression scope.
In C, variable names in a function prototype have expression scope, known in this context as function protocol scope. As the variable names in the prototype are not referred to —they are just dummies—these are often omitted, though they may be used for generating documentation, for instance.

Block scope

Many, but not all, block-structured programming languages allow scope to be restricted to a block, which is known as block scope. This began with ALGOL 60, where "very declaration... is valid only for that block.", and today is particularly associated with languages in the Pascal and C families and traditions. Most often this block is contained within a function, thus restricting the scope to a part of a function, but in some cases, such as Perl, the block may not be within a function.

unsigned int sum_of_squares

A representative example of the use of block scope is the C code shown here, where two variables are scoped to the loop: the loop variable n, which is initialized once and incremented on each iteration of the loop, and the auxiliary variable n_squared, which is initialized at each iteration. The purpose is to avoid adding variables to the function scope that are only relevant to a particular block—for example, this prevents errors where the generic loop variable i has accidentally already been set to another value. In this example the expression n * n would generally not be assigned to an auxiliary variable, and the body of the loop would simply be written ret += n * n but in more complicated examples auxiliary variables are useful.
Blocks are primarily used for control flow, such as with if, while, and for loops, and in these cases block scope means the scope of variable depends on the structure of a function's flow of execution. However, languages with block scope typically also allow the use of "naked" blocks, whose sole purpose is to allow fine-grained control of variable scope. For example, an auxiliary variable may be defined in a block, then used and discarded when the block ends, or a while loop might be enclosed in a block that initializes variables used inside the loop that should only be initialized once.
A subtlety of several programming languages, such as Algol 68 and C, is that block-scope variables can be declared not only within the body of the block, but also within the control statement, if any. This is analogous to function parameters, which are declared in the function declaration, and in scope for the whole function body. This is primarily used in for loops, which have an initialization statement separate from the loop condition, unlike while loops, and is a common idiom.
Block scope can be used for shadowing. In this example, inside the block the auxiliary variable could also have been called n, shadowing the parameter name, but this is considered poor style due to the potential for errors. Furthermore, some descendants of C, such as Java and C#, despite having support for block scope, do not allow one local variable to hide another. In such languages, the attempted declaration of the second n would result in a syntax error, and one of the n variables would have to be renamed.
If a block is used to set the value of a variable, block scope requires that the variable be declared outside of the block. This complicates the use of conditional statements with single assignment. For example, in Python, which does not use block scope, one may initialize a variable as such:

if c:
a = 'foo'
else:
a =

where a is accessible after the if statement.
In Perl, which has block scope, this instead requires declaring the variable prior to the block:

my $a;
if else

Often this is instead rewritten using multiple assignment, initializing the variable to a default value. In Python this would be:

a =
if c:
a = 'foo'

while in Perl this would be:

my $a = '';
if

In case of a single variable assignment, an alternative is to use the ternary operator to avoid a block, but this is not in general possible for multiple variable assignments, and is difficult to read for complex logic.
This is a more significant issue in C, notably for string assignment, as string initialization can automatically allocate memory, while string assignment to an already initialized variable requires allocating memory, a string copy, and checking that these are successful.

sub increment_counter

Some languages allow the concept of block scope to be applied, to varying extents, outside of a function. For example, in the Perl snippet at right, $counter is a variable name with block scope, while increment_counter is a function name with global scope. Each call to increment_counter will increase the value of $counter by one, and return the new value. Code outside of this block can call increment_counter, but cannot otherwise obtain or alter the value of $counter. This idiom allows one to define closures in Perl.

Function scope

Most of the commonly used programming languages offer a way to create a local variable in a function or subroutine: a variable whose scope ends when the function returns. In most cases the lifetime of the variable is the duration of the function call—it is an automatic variable, created when the function starts, destroyed when the function returns—while the scope of the variable is within the function, though the meaning of "within" depends on whether scoping is lexical or dynamic. However, some languages, such as C, also provide for static local variables, where the lifetime of the variable is the entire lifetime of the program, but the variable is only in context when inside the function. In the case of static local variables, the variable is created when the program initializes, and destroyed only when the program terminates, as with a static global variable, but is only in context within a function, like an automatic local variable.
Importantly, in lexical scoping a variable with function scope has scope only within the lexical context of the function: it moves out of context when another function is called within the function, and moves back into context when the function returns—called functions have no access to the local variables of calling functions, and local variables are only in context within the body of the function in which they are declared. By contrast, in dynamic scoping, the scope extends to the runtime context of the function: local variables stay in context when another function is called, only moving out of context when the defining function ends, and thus local variables are in context of the function in which they are defined and all called functions. In languages with lexical scoping and nested functions, local variables are in context for nested functions, since these are within the same lexical context, but not for other functions that are not lexically nested. A local variable of an enclosing function is known as a non-local variable for the nested function. Function scope is also applicable to anonymous functions.

def square:
return n * n
def sum_of_squares:
total = 0
i = 0
while i <= n:
total += square
i += 1
return total

For example, in the snippet of Python code on the right, two functions are defined: square and sum_of_squares. square computes the square of a number; sum_of_squares computes the sum of all squares up to a number. is 4² = 16, and sum_of_squares Each of these functions has a variable named n that represents the argument to the function. These two n variables are completely separate and unrelated, despite having the same name, because they are lexically scoped local variables with function scope: each one's scope is its own, lexically separate function and thus, they don't overlap. Therefore, sum_of_squares can call square without its own n being altered. Similarly, sum_of_squares has variables named total and i; these variables, because of their limited scope, will not interfere with any variables named total or i that might belong to any other function. In other words, there is no risk of a name collision between these identifiers and any unrelated identifiers, even if they are identical. No name masking is occurring: only one variable named n is in context at any given time, as the scopes do not overlap. By contrast, were a similar fragment to be written in a language with dynamic scope, the n in the calling function would remain in context in the called function—the scopes would overlap—and would be masked by the new n in the called function. Function scope is significantly more complicated if functions are first-class objects and can be created locally to a function and then returned. In this case any variables in the nested function that are not local to it create a closure, as not only the function itself, but also its environment must be returned, and then potentially called in a different context. This requires significantly more support from the compiler, and can complicate program analysis.File scope A scoping rule largely particular to C is file scope, where scope of variables and functions declared at the top level of a file is for the entire file—or rather for C, from the declaration until the end of the source file, or more precisely translation unit. This can be seen as a form of module scope, where modules are identified with files, and in more modern languages is replaced by an explicit module scope. Due to the presence of include statements, which add variables and functions to the internal context and may themselves call further include statements, it can be difficult to determine what is in context in the body of a file. In the C code snippet above, the function name sum_of_squares has file scope.Module scope In modular programming, the scope of a name can be an entire module, however it may be structured across various files. In this paradigm, modules are the basic unit of a complex program, as they allow information hiding and exposing a limited interface. Module scope was pioneered in the Modula family of languages, and Python is a representative contemporary example. In some object-oriented programming languages that lack direct support for modules, such as C++, a similar structure is instead provided by the class hierarchy, where classes are the basic unit of the program, and a class can have private methods. This is properly understood in the context of dynamic dispatch rather than name resolution and scope, though they often play analogous roles. In some cases both these facilities are available, such as in Python, which has both modules and classes, and code organization is a choice of the programmer.Global scope A declaration has global scope if it has effect throughout an entire program. Variable names with global scope — called global variables — are frequently considered bad practice, at least in some languages, due to the possibility of name collisions and unintentional masking, together with poor modularity, and function scope or block scope are considered preferable. However, global scope is typically used for various other sorts of identifiers, such as names of functions, and names of classes and other data types. In these cases mechanisms such as namespaces are used to avoid collisions.Lexical scoping vs. dynamic scoping The use of local variables — of variable names with limited scope, that only exist within a specific function — helps avoid the risk of a name collision between two identically named variables. However, there are two very different approaches to answering this question: What does it mean to be "within" a function? In lexical scoping, if a variable name's scope is a certain function, then its scope is the program text of the function definition: within that text, the variable name exists, and is bound to the variable's value, but outside that text, the variable name does not exist. By contrast, in dynamic scoping, if a variable name's scope is a certain function, then its scope is the time-period during which the function is executing: while the function is running, the variable name exists, and is bound to its value, but after the function returns, the variable name does not exist. This means that if function f invokes a separately defined function g, then under lexical scoping, function g does not have access to f's local variables, while under dynamic scoping, function g does have access to f's local variables. $ # bash language $ x=1 $ function g $ function f $ f # does this print 1, or 3? $ echo $x # does this print 1, or 2? Consider, for example, the program on the right. The first line, x=1, creates a global variable x and initializes it to 1. The second line, function g , defines a function g that prints out the current value of x, and then sets x to 2. The third line, function f defines a function f that creates a local variable x and initializes it to 3, and then calls g. The fourth line, f, calls f. The fifth line, echo $x, prints out the current value of x. So, what exactly does this program print? It depends on the scoping rules. If the language of this program is one that uses lexical scoping, then g prints and modifies the global variable x, so the program prints 1 and then 2. By contrast, if this language uses dynamic scoping, then g prints and modifies f's local variable x, so the program prints 3 and then 1.Lexical scoping With lexical scope, a name always refers to its local lexical environment. This is a property of the program text and is made independent of the runtime call stack by the language implementation. Because this matching only requires analysis of the static program text, this type of scoping is also called static scoping. Lexical scoping is standard in all ALGOL-based languages such as Pascal, Modula-2 and Ada as well as in modern functional languages such as ML and Haskell. It is also used in the C language and its syntactic and semantic relatives, although with different kinds of limitations. Static scoping allows the programmer to reason about object references such as parameters, variables, constants, types, functions, etc. as simple name substitutions. This makes it much easier to make modular code and reason about it, since the local naming structure can be understood in isolation. In contrast, dynamic scope forces the programmer to anticipate all possible dynamic contexts in which the module's code may be invoked. program A; var I:integer; K:char; procedure B; var K:real; L:integer; procedure C; var M:real; begin end; end; end. For example, Pascal is lexically scoped. Consider the Pascal program fragment at right. The variable I is visible at all points, because it is never hidden by another variable of the same name. The char variable K is visible only in the main program because it is hidden by the real variable K visible in procedure B and C only. Variable L is also visible only in procedure B and C but it does not hide any other variable. Variable M is only visible in procedure C and therefore not accessible either from procedure B or the main program. Also, procedure C is visible only in procedure B and can therefore not be called from the main program. There could have been another procedure C declared in the program outside of procedure B. The place in the program where "C" is mentioned then determines which of the two procedures named C it represents, thus precisely analogous with the scope of variables. Correct implementation of static scope in languages with first-class nested functions is not trivial, as it requires each function value to carry with it a record of the values of the variables that it depends on. Depending on implementation and computer architecture, variable lookup may become slightly inefficient when very deeply lexically nested functions are used, although there are well-known techniques to mitigate this. Also, for nested functions that only refer to their own arguments and local variables, all relative locations can be known at compile time. No overhead at all is therefore incurred when using that type of nested function. The same applies to particular parts of a program where nested functions are not used, and, naturally, to programs written in a language where nested functions are not available.History Lexical scoping was used for the imperative language ALGOL 60 and has been picked up in most other imperative languages since then. Languages like Pascal and C have always had lexical scoping, since they are both influenced by the ideas that went into ALGOL 60 and ALGOL 68. Perl is a language with dynamic scoping that added static scoping afterwards. The original Lisp interpreter used dynamic scoping. Deep binding, which approximates static scoping, was introduced in LISP 1.5. All early Lisps used dynamic scoping, at least when based on interpreters. In 1982, Guy L. Steele Jr. and the Common LISP Group publish An overview of Common LISP, a short review of the history and the divergent implementations of Lisp up to that moment and a review of the features that a Common Lisp implementation should have. On page 102, we read: Most LISP implementations are internally inconsistent in that by default the interpreter and compiler may assign different semantics to correct programs; this stems primarily from the fact that the interpreter assumes all variables to be dynamically scoped, while the compiler assumes all variables to be local unless forced to assume otherwise. This has been done for the sake of convenience and efficiency, but can lead to very subtle bugs. The definition of Common LISP avoids such anomalies by explicitly requiring the interpreter and compiler to impose identical semantics on correct programs. Implementations of Common LISP were thus required to have lexical scoping. Again, from An overview of Common LISP: In addition, Common LISP offers the following facilities : Fully lexically scoped variables. The so-called "FUNARG problem" is completely solved, in both the downward and upward cases. By the same year in which An overview of Common LISP was published, initial designs of a compiled, lexically scoped Lisp, called Scheme had been published and compiler implementations were being attempted. At that time, lexical scoping in Lisp was commonly feared to be inefficient to implement. In A History of T, Olin Shivers writes: All serious Lisps in production use at that time were dynamically scoped. No one who hadn't carefully read the Rabbit thesis believed lexical scope would fly; even the few people who had read it were taking a bit of a leap of faith that this was going to work in serious production use. The term "lexical scope" dates at least to 1967, while the term "lexical scoping" dates at least to 1970, where it was used in Project MAC to describe the scoping rules of the Lisp dialect MDL.Dynamic scoping With dynamic scope, a global identifier refers to the identifier associated with the most recent environment, and is uncommon in modern languages. In technical terms, this means that each identifier has a global stack of bindings. Introducing a local variable with name x pushes a binding onto the global x stack, which is popped off when the control flow leaves the scope. Evaluating x in any context always yields the top binding. Note that this cannot be done at compile-time because the binding stack only exists at run-time, which is why this type of scoping is called dynamic scoping. Generally, certain blocks are defined to create bindings whose lifetime is the execution time of the block; this adds some features of static scoping to the dynamic scoping process. However, since a section of code can be called from many different locations and situations, it can be difficult to determine at the outset what bindings will apply when a variable is used. This can be beneficial; application of the principle of least knowledge suggests that code avoid depending on the reasons for a variable's value, but simply use the value according to the variable's definition. This narrow interpretation of shared data can provide a very flexible system for adapting the behavior of a function to the current state of the system. However, this benefit relies on careful documentation of all variables used this way as well as on careful avoidance of assumptions about a variable's behavior, and does not provide any mechanism to detect interference between different parts of a program. Dynamic scoping also voids all the benefits of referential transparency. As such, dynamic scoping can be dangerous and few modern languages use it. Some languages, like Perl and Common Lisp, allow the programmer to choose static or dynamic scoping when defining or redefining a variable. Examples of languages that use dynamic scoping include Logo, Emacs Lisp, LaTeX and the shell languages bash, dash, and PowerShell. Dynamic scoping is fairly easy to implement. To find an identifier's value, the program could traverse the runtime stack, checking each activation record for a value for the identifier. In practice, this is made more efficient via the use of an association list, which is a stack of name/value pairs. Pairs are pushed onto this stack whenever declarations are made, and popped whenever variables go out of scope. Shallow binding is an alternative strategy that is considerably faster, making use of a central reference table, which associates each name with its own stack of meanings. This avoids a linear search during run-time to find a particular name, but care should be taken to properly maintain this table. Note that both of these strategies assume a last-in-first-out ordering to bindings for any one variable; in practice all bindings are so ordered. An even simpler implementation is the representation of dynamic variables with simple global variables. The local binding is performed by saving the original value in an anonymous location on the stack that is invisible to the program. When that binding scope terminates, the original value is restored from this location. In fact, dynamic scope originated in this manner. Early implementations of Lisp used this obvious strategy for implementing local variables, and the practice survives in some dialects which are still in use, such as GNU Emacs Lisp. Lexical scope was introduced into Lisp later. This is equivalent to the above shallow binding scheme, except that the central reference table is simply the global variable binding environment, in which the current meaning of the variable is its global value. Maintaining global variables isn't complex. For instance, a symbol object can have a dedicated slot for its global value. Dynamic scoping provides an excellent abstraction for thread local storage, but if it is used that way it cannot be based on saving and restoring a global variable. A possible implementation strategy is for each variable to have a thread-local key. When the variable is accessed, the thread-local key is used to access the thread-local memory location. If the thread-local key does not exist for the calling thread, then the global location is used. When a variable is locally bound, the prior value is stored in a hidden location on the stack. The thread-local storage is created under the variable's key, and the new value is stored there. Further nested overrides of the variable within that thread simply save and restore this thread-local location. When the initial, outer-most override's scope terminates, the thread-local key is deleted, exposing the global version of the variable once again to that thread.Macro expansion In modern languages, macro expansion in a preprocessor is a key example of de facto dynamic scope. The macro language itself only transforms the source code, without resolving names, but since the expansion is done in place, when the names in the expanded text are then resolved, they are resolved based on where they are expanded, as if dynamic scoping were occurring. The C preprocessor, used for macro expansion, has de facto dynamic scope, as it does not do name resolution by itself. For example, the macro: define ADD_A x + a will expand to add a to the passed variable, with this identifier only later resolved by the compiler based on where the macro ADD_A is "called", is in dynamic scope, and is independent of where the macro is defined. Properly, the C preprocessor only does lexical analysis, expanding the macro during the tokenization stage, but not parsing into a syntax tree or doing name resolution. For example, in the following code, the a in the macro is resolved to the local variable at the expansion site: define ADD_A x + a void add_one void add_two Qualified identifiers As we have seen, one of the key reasons for scope is that it helps prevent name collisions, by allowing identical identifiers to refer to distinct things, with the restriction that the identifiers must have separate scopes. Sometimes this restriction is inconvenient; when many different things need to be accessible throughout a program, they generally all need identifiers with global scope, so different techniques are required to avoid name collisions. To address this, many languages offer mechanisms for organizing global identifiers. The details of these mechanisms, and the terms used, depend on the language; but the general idea is that a group of identifiers can itself be given a name — a prefix — and, when necessary, an entity can be referred to by a qualified identifier consisting of the identifier plus the prefix. Normally such identifiers will have, in a sense, two sets of scopes: a scope in which the qualified identifier is visible, and one or more narrower scopes in which the unqualified identifier is visible as well. And normally these groups can themselves be organized into groups; that is, they can be nested. Although many languages support this concept, the details vary greatly. Some languages have mechanisms, such as namespaces in C++ and C#, that serve almost exclusively to enable global identifiers to be organized into groups. Other languages have mechanisms, such as packages in Ada and structures in Standard ML, that combine this with the additional purpose of allowing some identifiers to be visible only to other members of their group. And object-oriented languages often allow classes or singleton objects to fulfill this purpose. Furthermore, languages often meld these approaches; for example, Perl's packages are largely similar to C++'s namespaces, but optionally double as classes for object-oriented programming; and Java organizes its variables and functions into classes, but then organizes those classes into Ada-like packages.By language Scoping rules for representative languages follow.C In C, scope is traditionally known as linkage or visibility, particularly for variables. C is a lexically scoped language with global scope, a form of module scope or file scope, and local scope ; within a function scopes can further be nested via block scope. However, standard C does not support nested functions. The lifetime and visibility of a variable are determined by its storage class. There are three types of lifetimes in C: static, automatic, and manual. Only static and automatic are supported for variables and handled by the compiler, while manually allocated memory must be tracked manually across different variables. There are three levels of visibility in C: external linkage, internal linkage, and block scope ; block scopes can be nested, and different levels of internal linkage is possible by use of includes. Internal linkage in C is visibility at the translation unit level, namely a source file after being processed by the C preprocessor, notably including all relevant includes. C programs are compiled as separate object files, which are then linked into an executable or library via a linker. Thus name resolution is split across the compiler, which resolves names within a translation unit, and the linker, which resolves names across translation units; see linkage for further discussion. In C, variables with block scope enter scope when they are declared, move out of scope if any function is called within the block, move back into scope when the function returns, and move out of scope at the end of the block. In the case of automatic local variables, they are also allocated on declaration and deallocated at the end of the block, while for static local variables, they are allocated at program initialization and deallocated at program termination. The following program demonstrates a variable with block scope coming into scope partway through the block, then exiting scope when the block ends: include int main The program outputs There are other levels of scope in C. Variable names used in a function prototype have function prototype visibility, and exit scope at the end of the function prototype. Since the name is not used, this is not useful for compilation, but may be useful for documentation. Label names for GOTO statement have function scope, while case label names for switch statements have block scope.C++ All the variables that we intend to use in a program must have been declared with its type specifier in an earlier point in the code, like we did in the previous code at the beginning of the body of the function main when we declared that a, b, and result were of type int. A variable can be either of global or local scope. A global variable is a variable declared in the main body of the source code, outside all functions, while a local variable is one declared within the body of a function or a block. Modern versions allow nested lexical scoping.Go is lexically scoped using blocks.Java is lexically scoped. A Java class can contain three types of variables: ;Local variables: are defined inside a method, or a particular block. These variables are local to where they were defined and lower levels. For example, a loop inside a method can use that method's local variables, but not the other way around. The loop's variables are destroyed as soon as the loop ends. ;Member variables: also called fields are variables declared within the class, outside of any method. By default, these variables are available for all methods within that class and also for all classes in the package. ;Parameters: are variables in method declarations. In general, a set of brackets defines a particular scope, but variables at top level within a class can differ in their behavior depending on the modifier keywords used in their definition. The following table shows the access to members permitted by each modifier. Modifier Class Package Subclass World public protected private JavaScript has simple scoping rules, but variable initialization and name resolution rules can cause problems, and the widespread use of closures for callbacks means the lexical environment of a function when defined can be very different from the lexical environment when it is called. JavaScript objects have name resolution for properties, but this is a separate topic. JavaScript has lexical scoping nested at the function level, with the global scope being the outermost scope. This scoping is used for both variables and for functions. Block scoping with the let and const keywords is standard since ECMAScript 6. Block scoping can be produced by wrapping the entire block in a function and then executing it; this is known as the immediately-invoked function expression pattern. While JavaScript scoping is simple—lexical, function-level—the associated initialization and name resolution rules are a cause of confusion. Firstly, assignment to a name not in scope defaults to creating a new global variable, not a local one. Secondly, to create a new local variable one must use the var keyword; the variable is then created at the top of the function, with value undefined and the variable is assigned its value when the assignment expression is reached: This is known as variable hoisting—the declaration, but not the initialization, is hoisted to the top of the function. Thirdly, accessing variables before initialization yields undefined, rather than a syntax error. Fourthly, for function declarations, the declaration and the initialization are both hoisted to the top of the function, unlike for variable initialization. For example, the following code produces a dialog with output undefined, as the local variable declaration is hoisted, shadowing the global variable, but the initialization is not, so the variable is undefined when used: a = 1; function f f; Further, as functions are first-class objects in JavaScript and are frequently assigned as callbacks or returned from functions, when a function is executed, the name resolution depends on where it was originally defined, not the lexical environment or execution environment where it is called. The nested scopes of a particular function in JavaScript, particularly of a closure, used as a callback, are sometimes referred to as the scope chain, by analogy with the prototype chain of an object. Closures can be produced in JavaScript by using nested functions, as functions are first-class objects. Returning a nested function from an enclosing function includes the local variables of the enclosing function as the lexical environment of the returned function, yielding a closure. For example: function newCounter c = newCounter; alert + ' ' + c); // outputs "1 2" Closures are frequently used in JavaScript, due to being used for callbacks. Indeed, any hooking of a function in the local environment as a callback or returning it from a function creates a closure if there are any unbound variables in the function body ; this may be accidental. When creating a callback based on parameters, the parameters must be stored in a closure, otherwise it will accidentally create a closure that refers to the variables in the enclosing environment, which may change. Name resolution of properties of JavaScript objects is based on inheritance in the prototype tree—a path to the root in the tree is called a prototype chain—and is separate from name resolution of variables and functions.Lisp dialects have various rules for scoping. The original Lisp used dynamic scoping; it was Scheme, inspired by Algol, that introduced static scoping to the Lisp family. Maclisp used dynamic scope by default in the interpreter and lexical scope by default in compiled code, though compiled code could access dynamic bindings by use of SPECIAL declarations for particular variables. However, Maclisp treated lexical binding more as an optimization than one would expect in modern languages, and it did not come with the closure feature one might expect of lexical scoping in modern Lisps. A separate operation, *FUNCTION, was available to somewhat clumsily work around some of that issue. Common Lisp adopted lexical scoping from Scheme, as did Clojure. ISLISP has lexical scoping for ordinary variables. It also has dynamic variables, but they are in all cases explicitly marked; they must be defined by a defdynamic special form, bound by a dynamic-let special form, and accessed by an explicit dynamic special form. Some other dialects of Lisp, like Emacs Lisp, still use dynamic scoping by default. Emacs Lisp now has lexical scoping available on a per-buffer basis.Python For variables, Python has function scope, module scope, and global scope. Names enter scope at the start of a context, and exit scope when a non-nested function is called or the context ends. If a name is used prior to variable initialization, this raises a runtime exception. If a variable is simply accessed in a context, name resolution follows the LEGB rule. However, if a variable is assigned to, it defaults to creating a local variable, which is in scope for the entire context. Both these rules can be overridden with a global or nonlocal declaration prior to use, which allows accessing global variables even if there is an intervening nonlocal variable, and assigning to global or nonlocal variables. As a simple example, a function resolves a variable to the global scope: >>> def f: ... print ... >>> x = 'global' >>> f global Note that x is initialized before f is called, so no error is raised, even though it is declared after f is declared. Lexically this is a forward reference, which is allowed in Python. Here assignment creates a new local variable, which does not change the value of the global variable: >>> def f: ... x = 'f' ... print ... >>> x = 'global' >>> print global >>> f >>> print global Assignment to a variable within a function causes it to be declared local to the function, and thus using it prior to this assignment raises an error. This differs from C, where the local variable is only in scope from its declaration, not for the entire function. This code raises an error: >>> def f: ... print ... x = 'f' ... >>> x = 'global' >>> f Traceback : File "", line 1, in File "", line 2, in f UnboundLocalError: local variable 'x' referenced before assignment The default name resolution rules can be overridden with the global or nonlocal keywords. In the below code, the global x declaration in g means that x resolves to the global variable. It thus can be accessed, and assignment assigns to the global variable, rather than declaring a new local variable. Note that no global declaration is needed in f—since it does not assign to the variable, it defaults to resolving to the global variable. >>> def f: ... print ... >>> def g: ... global x ... print ... x = 'g' ... >>> x = 'global' >>> f global >>> g global >>> f global can also be used for nested functions. In addition to allowing assignment to a global variable, as in an unnested function, this can also be used to access the global variable in the presence of a nonlocal variable: >>> x = 'global' >>> def f: ... def g: ... global x ... print ... x = 'f' ... g ... >>> f global For nested functions, there is also the nonlocal declaration, for assigning to a nonlocal variable, similar to using global in an unnested function: >>> def f: ... def g: ... nonlocal x # Python 3.x only ... x = 'g' ... x = 'f' ... g ... print ... >>> x = 'global' >>> f >>> print global R is a lexically scoped language, unlike other implementations of S where the values of free variables are determined by a set of global variables, while in R they are determined by the environment in which the function was created. The scoping environments may be accessed using a variety of features which can simulate the experience of dynamic scoping should the programmer desire. no block scoping a <- 1 message # 2 functions have access to environment they were created in a <- 1 f <- function f # 1 variables created or modified within a function stay there a <- 1 f <- function f # 1 # 2 message # 1 variables created or modified within a function stay there unless assignment to enclosing environment is explicitly requested a <- 1 f <- function f # 1 # 2 message # 2 although R has lexical scoping by default, function scopes can be changed a <- 1 f <- function my_env <- new.env my_env$a <- 2 f # 1 environment <- my_env f # 2

Popular articles Javier Milei - Argentine libertarian economist, author, radio conductor and public speaker sympathetic to the Austrian School of economic thought. He became widely known for his regular ... Jimmy Carter - American politician, philanthropist, and former farmer who served as the 39th president of the United States from 1977 to 1981. A member of the Democratic Party, he previ... UEFA Euro 2024 - The 2024 UEFA European Football Championship , commonly referred to as UEFA Euro 2024 or simply Euro 2024 , will be the 17th edition of the UEFA European Championship, the quadrennial internationa... Argentina - country located mostly in the southern half of South America. Sharing the bulk of the Southern Cone with Chile to the west, the country is also b... Sam Altman - American entrepreneur, investor, programmer, and blogger. He is the former president of Y Combinator and now the CEO of OpenAI. Early life and education. ... Rosalynn Carter - American who served as First Lady of the United States from 1977 to 1981 as the wife of President Jimmy Carter. For decades, she has been a leading advocate for numerou... Next Argentine presidential election - Next Argentine presidential election - presidential election in Argentina.... Popular movies The Hunger Games (film) - 2012 American dystopian action thriller science fiction-adventure film directed by Gary Ross and based on Suzanne Collins’s 2008 novel of the same name. It is the first insta... untitled Captain Marvel sequel - part of Marvel Cinematic Universe.... Killers of the Flower Moon (film project) - Killers of the Flower Moon - film project in United States of America. It was presented as drama, detective fiction, thriller. The film project starred Leonardo Dicaprio, Robert De Niro. Director of... Five Nights at Freddy's (film) - Five Nights at Freddy's - film published in 2017 in United States of America. Scenarist of the film - Scott Cawthon.... Popular video games Minecraft - sandbox video game developed by Mojang Studios. Created by Markus "Notch" Persson in the Java programming language and released as a public alpha for personal computers in 2... Grand Theft Auto V - 2013 action-adventure game developed by Rockstar North and published by Rockstar Games. It is the first main entry in the Grand Theft Auto series since 2008's Grand Theft ... Roblox - online game platform and game creation system that allows users to program games and play games created by other users. Founded by David Baszucki and Erik Cassel in 2004 and released in... Baldur's Gate III - upcoming role-playing video game developed and published by Larian Studios for Microsoft Windows and the Stadia streaming service. It is the third main game in the Baldur's ... Alan Wake - action-adventure video game developed by Remedy Entertainment and published by Microsoft Studios, released for the Xbox 360 and Microsoft Windows. The story follows best-selling thri... Fortnite - online video game developed by Epic Games and released in 2017. It is available in three distinct game mode versions that otherwise share the same general gameplay and game engine: ... Super Mario RPG - is a role-playing video game developed by Square and published by Nintendo for the Super Nintendo Entertainment System in 1996. It was directed by Yoshihiko Maekawa and Chihiro Fujioka and produced by... Popular books Book of Revelation - The Book of Revelation is the final book of the New Testament, and consequently is also the final book of the Christian Bible. Its title is derived from the first word of the Koine Greek text: apok... Book of Genesis - account of the creation of the world, the early history of humanity, Israel's ancestors and the origins... Gospel of Matthew - The Gospel According to Matthew is the first book of the New Testament and one of the three synoptic gospels. It tells how Israel's Messiah, rejected and executed in Israel, pronounces judgement on ... Michelin Guide - Michelin Guides are a series of guide books published by the French tyre company Michelin for more than a century. The term normally refers to the annually published Michelin Red Guide , the oldest... Psalms - The Book of Psalms , commonly referred to simply as Psalms , the Psalter or "the Psalms", is the first book of the Ketuvim , the third section of the Hebrew Bible, and thus a book of th... Ecclesiastes - Ecclesiastes is one of 24 books of the Tanakh , where it is classified as one of the Ketuvim . Originally written c. 450–200 BCE, it is also among the canonical Wisdom literature of the Old Tes... The 48 Laws of Power - non-fiction book by American author Robert Greene. The book... Popular television series The Crown (TV series) - historical drama web television series about the reign of Queen Elizabeth II, created and principally written by Peter Morgan, and produced by Left Bank Pictures and Sony Pictures Tel... Friends - American sitcom television series, created by David Crane and Marta Kauffman, which aired on NBC from September 22, 1994, to May 6, 2004, lasting ten seasons. With an ensemble cast sta... Young Sheldon - spin-off prequel to The Big Bang Theory and begins with the character Sheldon... Modern Family - American television mockumentary family sitcom created by Christopher Lloyd and Steven Levitan for the American Broadcasting Company. It ran for eleven seasons, from September 23... Loki (TV series) - upcoming American web television miniseries created for Disney+ by Michael Waldron, based on the Marvel Comics character of the same name. It is set in the Marvel Cinematic Universe, shar... Game of Thrones - American fantasy drama television series created by David Benioff and D. B. Weiss for HBO. It... Shameless (American TV series) - American comedy-drama television series developed by John Wells which debuted on Showtime on January 9, 2011. It...