Scope (computer programming)

Lexical scope vs. dynamic scope

A fundamental distinction in scope is what "part of a program" means. In languages with lexical scope (also called static scope), name resolution depends on the location in the source code and the lexical context (also called static 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 (also called runtime context, calling context or dynamic context). In practice, with lexical scope a name is resolved by searching the local lexical context, then if that fails, by searching the outer lexical context, and so on; whereas with dynamic scope, a name is resolved by searching the local execution context, then if that fails, by searching the outer execution context, and so on, progressing up the call stack.^[4]

Most modern languages use lexical scope for variables and functions, though dynamic scope is used in some languages, notably some dialects of Lisp, some "scripting" languages, and some template languages.^[c] Perl 5 offers both lexical and dynamic scope. Functions that use lexically scoped variables are known as closures.

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 scope is common in macro languages, which do not directly do name resolution, but instead expand in place.

Some programming frameworks like AngularJS use syntactically the term "scope" to mean — the semantics of word — 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 (JavaScript in case of AngularJS) 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 context or not in context (using the usual meaning of the term) 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" (with a dollar sign) is used to avoid confusion, but using the dollar sign in variable names is often discouraged by the style guides.^[5]

Expression scope

The scope of a name binding is an expression, which is known as expression scope. Expression scope is available in many languages, especially functional languages which offer a feature called let expressions allowing 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 { my $x = f(); $x * $x }, or in GNU C as ({ int x = f(); x * x; }).

In Python, auxiliary variables in generator expressions and list comprehensions (in Python 3) 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 may be different in the actual definition)—they are just dummies—these are often omitted, though they may be used for generating documentation, for instance.

Block scope

The scope of a name binding is a block, which is known as block scope. Block scope is available in many, but not all, block-structured programming languages. This began with ALGOL 60, where "[e]very declaration ... is valid only for that block.",^[6] 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.

int sum_of_squares(int m) {
    int result = 0;
    for (int n = 1; n <= m; ++n) {
        const int n_squared = n * n;
        result += n_squared;
    }
    return result;
}

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 result += 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 (say, added to a variable with function scope) 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 (demonstrated in this example and standardized since C99), 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 (before the block of the function body starts), 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 (in that a local variable can be made to go out of context before the end of a function), 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 (c) {
    $a = 'foo';
} else {
    $a = '';
}

Often this is instead rewritten using multiple assignment, initializing the variable to a default value. In Python (where it is not necessary) this would be:

a = ""
if c:
    a = "foo"

while in Perl this would be:

my $a = '';
if (c) {
    $a = 'foo';
}

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.

{
  my $counter = 0;
  sub increment_counter {
      return  ++$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 (due to the use of the my keyword), 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

When the scope of variables declared within a function does not extend beyond that function, this is known as function scope.^[7] Function scope is available in most programming languages which offer a way to create a local variable in a function or subroutine: a variable whose scope ends (that goes out of context) 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 (or the variable is declared), destroyed when the function returns—while the scope of the variable is within the function, though the meaning of "within" depends on whether scope 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 scope a variable with function scope has scope only within the lexical context of the function: it goes out of context when another function is called within the function, and comes 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 scope, the scope extends to the execution context of the function: local variables stay in context when another function is called, only going 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 scope 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(n: int) -> int:
    return n * n

def sum_of_squares(n: int) -> int:
    total: int = 0 
    i: int = 0
    while i <= n:
        total += square(i)
        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. (For example, square(4) is 4² = 16, and sum_of_squares(4) is 0² + 1² + 2² + 3² + 4² = 30.)

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 names and any unrelated names, 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 ("shadowed") 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 by a function and then returned. In this case any variables in the nested function that are not local to it (unbound variables in the function definition, that resolve to variables in an enclosing context) create a closure, as not only the function itself, but also its context (of variables) 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

The scope of a name binding is a file, which is known as file scope. File scope is largely particular to C (and C++), where scope of variables and functions declared at the top level of a file (not within any function) is for the entire file—or rather for C, from the declaration until the end of the source file, or more precisely translation unit (internal linking). 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 global scope (in C, extern linkage). Adding static to the function signature would result in file scope (internal linkage).

Module scope

The scope of a name binding is a module, which is known as module scope. Module scope is available in modular programming languages where modules (which may span various files) 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 (which was influenced by Modula) is a representative contemporary example.

In some object-oriented programming languages that lack direct support for modules, such as C++ before C++20,^[8] 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 (as a module-level function or a conventionally private method) is a choice of the programmer.

Global scope

The scope of a name binding is an entire program, which is known as global scope. 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 (depending on the language) for various other sorts of names, such as names of functions, names of classes and names of other data types. In these cases mechanisms such as namespaces are used to avoid collisions.

History

Lexical scope was first used in the early 1960s for the imperative language ALGOL 60 and has been picked up in most other imperative languages since then.^[4]

Languages like Pascal and C have always had lexical scope, since they are both influenced by the ideas that went into ALGOL 60 and ALGOL 68 (although C did not include lexically nested functions).

Perl is a language with dynamic scope that added static scope afterwards.^{[citation needed]}

The original Lisp interpreter (1960) used dynamic scope. Deep binding, which approximates static (lexical) scope, was introduced around 1962 in LISP 1.5 (via the Funarg device developed by Steve Russell, working under John McCarthy).

All early Lisps used dynamic scope, when based on interpreters. In 1982, Guy L. Steele Jr. and the Common Lisp Group published An overview of Common Lisp,^[11] 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 scope. Again, from An overview of Common Lisp:

In addition, Common LISP offers the following facilities (most of which are borrowed from MacLisp, InterLisp or Lisp Machines Lisp): (...) Fully lexically scoped variables. The so-called "FUNARG problem"^[12][13] is completely solved, in both the downward and upward cases.

By the same year in which An overview of Common LISP was published (1982), initial designs (also by Guy L. Steele Jr.) of a compiled, lexically scoped Lisp, called Scheme had been published and compiler implementations were being attempted. At that time, lexical scope in Lisp was commonly feared to be inefficient to implement. In A History of T,^[14] Olin Shivers writes:

All serious Lisps in production use at that time were dynamically scoped. No one who hadn't carefully read the Rabbit^[15] thesis (written by Guy Lewis Steele Jr. in 1978) 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,^[16] while the term "lexical scoping" dates at least to 1970, where it was used in Project MAC to describe the scope rules of the Lisp dialect MDL (then known as "Muddle").^[17]

Lexical scope in modern programming

In modern programming languages, lexical scope plays a crucial role in enabling functional programming paradigms. Languages like JavaScript^[18], Python^[19], and Swift^[20] rely heavily on lexical scoping to ensure that functions can access variables from their defining context, even if the function is executed outside its lexical scope. This is particularly important when dealing with closures, which are a direct consequence of lexical scoping.

For example, in JavaScript, closures are frequently used for asynchronous programming and event handling, as they allow callbacks to retain access to the variables from the outer scope, facilitating cleaner, more modular code. Similarly, Python and Swift utilize lexical scope to implement closures and enable powerful patterns like higher-order functions.^[21]

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 (notably free variables), they are resolved based on where they are expanded (loosely "called"), as if dynamic scope were occurring.

The C preprocessor, used for macro expansion, has de facto dynamic scope, as it does not resolve names by itself and it is independent of where the macro is defined. For example, the macro:

#define ADD_A(x) x + a

will expand to add a to the passed variable, with this name only later resolved by the compiler based on where the macro ADD_A is "called" (properly, expanded). 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 name a in the macro is resolved (after expansion) to the local variable at the expansion site:

#define ADD_A(x) (x + a)

void add_one(int* x) {
    const int a = 1;
    *x = ADD_A(*x);
}

void add_two(int* x) {
    const int a = 2;
    *x = ADD_A(*x);
}

C

In C, scope is traditionally known as linkage or visibility, particularly for variables. C is a lexically scoped language with global scope (known as external linkage), a form of module scope or file scope (known as internal linkage), and local scope (within a function); 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 (program execution), automatic (block execution, allocated on the stack), and manual (allocated on the heap). 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 (global), internal linkage (roughly file), and block scope (which includes functions); 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 (more loosely, "compilation unit", but this is properly a different concept), and the linker, which resolves names across translation units; see linkage for further discussion.

In C, variables with block scope enter context when they are declared (not at the top of the block), go out of context if any (non-nested) function is called within the block, come back into context when the function returns, and go out of context 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 context partway through the block, then exiting context (and in fact being deallocated) when the block ends:

#include <stdio.h>

int main(void) {
    char x = 'm';
    printf("%c\n", x);

    {
        printf("%c\n", x);
        char x = 'b';
        printf("%c\n", x);
    }

    printf("%c\n", x);
}

The program outputs:

m
m
b
m

There are other levels of scope in C.^[23] Variable names used in a function prototype have function prototype visibility, and exit context 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.

C++

All the variables to use in a program must have been declared with its type specifier in an earlier point in the code, as done in the prior code at the start of the body of the function main when declaring 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 scope.

Swift

Swift has a similar rule for scopes with C++, but contains different access modifiers.

Go

Go is lexically scoped using blocks.^[3]

Java

Java is lexically scoped.

A Java class has several kinds of variables:^[24]

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 (local to that loop) 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.^[25]

JavaScript

JavaScript has simple scope rules,^[26] but variable initialization and name resolution rules can cause problems, and the widespread use of closures for callbacks means the lexical context of a function when defined (which is used for name resolution) can be very different from the lexical context when it is called (which is irrelevant for name resolution). JavaScript objects have name resolution for properties, but this is a separate topic.

JavaScript has lexical scope ^[27] nested at the function level, with the global context being the outermost context. This scope is used for both variables and for functions (meaning function declarations, as opposed to variables of function type).^[28] Block scope with the let and const keywords is standard since ECMAScript 6. Block scope can be produced by wrapping the entire block in a function and then executing it; this is known as the immediately-invoked function expression (IIFE) pattern.

While JavaScript scope 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:

A variable with an Initialiser is assigned the value of its AssignmentExpression when the VariableStatement is executed, not when the variable is created.^[29]

This is known as variable hoisting^[30]—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() {
  alert(a);
  var a = 2;
}
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 (the lexical context of the definition), not the lexical context or execution context where it is called. The nested scopes of a particular function (from most global to most local) 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.^[31] Returning a nested function from an enclosing function includes the local variables of the enclosing function as the (non-local) lexical context of the returned function, yielding a closure. For example:

function newCounter() {
  // return a counter that is incremented on call (starting at 0)
  // and which returns its new value
  var a = 0;
  var b = function() { a++; return a; };
  return b;
}
c = newCounter();
alert(c() + ' ' + 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 context as a callback or returning it from a function creates a closure if there are any unbound variables in the function body (with the context of the closure based on the nested scopes of the current lexical context, or "scope chain"); 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 context, which may change.^[32]

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

Lisp dialects have various rules for scope.

The original Lisp used dynamic scope; it was Scheme, inspired by ALGOL, that introduced static (lexical) scope 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.^[33] 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 scope in modern Lisps. A separate operation, *FUNCTION, was available to somewhat clumsily work around some of that issue.^[34]

Common Lisp adopted lexical scope from Scheme,^[35] as did Clojure.

ISLISP has lexical scope 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.^[36]

Some other dialects of Lisp, like Emacs Lisp, still use dynamic scope by default. Emacs Lisp now has lexical scope available on a per-buffer basis.^[37]

Python

For variables, Python has function scope, module scope, and global scope. Names enter context at the start of a scope (function, module, or global scope), and exit context when a non-nested function is called or the scope ends. If a name is used prior to variable initialization, this raises a runtime exception. If a variable is simply accessed (not assigned to), name resolution follows the LEGB (Local, Enclosing, Global, Built-in) rule which resolves names to the narrowest relevant context. However, if a variable is assigned to, it defaults to declaring a variable whose scope starts at the start of the level (function, module, or global), not at the assignment. Both these rules can be overridden with a global or nonlocal (in Python 3) declaration prior to use, which allows accessing global variables even if there is a masking nonlocal variable, and assigning to global or nonlocal variables.

As a simple example, a function resolves a variable to the global scope:

def f() -> None:
    print(x)

x: str = "global"
f()
# prints: global

Note that x is defined before f is called, so no error is raised, even though it is defined after its reference in the definition of f. 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() -> None:
    x: str = "f"
    print(x)

x: str = "global"
print(x)
# prints: global
f()
# prints: f
print(x)
# prints: global

Assignment to a variable within a function causes it to be declared local to the function, hence its scope is the entire function, and thus using it prior to this assignment raises an error. This differs from C, where the scope of the local variable start at its declaration. This code raises an error:

def f() -> None:
    print(x)
    x: str = "f"

x: str = "global"
f()
# Traceback (most recent call last):
#   File "<stdin>", line 1, in <module>
#   File "<stdin>", line 2, in f
# UnboundLocalError: local variable 'x' referenced before assignment

The default name resolution rules can be overridden with the global or nonlocal (in Python 3) keywords. In the below code, the global x declaration in g means that x resolves to the global variable. It thus can be accessed (as it has already been defined), 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() -> None:
    print(x)

def g() -> None:
    global x
    print(x)
    x = "g"

x: str = "global"
f()
# prints: global
g()
# prints: global
f()
# prints: g

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:

def f() -> None:
    def g() -> None:
        global x
        print(x)
    x: str = "f"
    g()

x: str = "global"
f()
# prints: 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() -> None:
    def g() -> None:
        nonlocal x  # Python 3 only
        x = "g"
    x: str = "f"
    g()
    print(x)

x: str = "global"
f()
# prints: g
print(x)
# prints: global

R

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 context in which the function was created.^[38] The scope contexts may be accessed using a variety of features (such as parent.frame()) which can simulate the experience of dynamic scope should the programmer desire.

There is no block scope:

a <- 1
{
  a <- 2
}
message(a)
## 2

Functions have access to scope they were created in:

a <- 1
f <- function() {
  message(a)
}
f()
## 1

Variables created or modified within a function stay there:

a <- 1
f <- function() {
  message(a)
  a <- 2
  message(a)
}
f()
## 1
## 2
message(a)
## 1

Variables created or modified within a function stay there unless assignment to enclosing scope is explicitly requested:

a <- 1
f <- function() {
  message(a)
  a <<- 2
  message(a)
}
f()
## 1
## 2
message(a)
## 2

Although R has lexical scope by default, function scopes can be changed:

a <- 1
f <- function() {
  message(a)
}
my_env <- new.env()
my_env$a <- 2
f()
## 1
environment(f) <- my_env
f()
## 2