Scope of variables

Each module forms a new global domain, independent of the global domains of the other modules - there is no comprehensive global domain. Variables from other modules can be entered into the module area using the operators using and import, as well as access them by qualified name through dot notation. That is, each module is a so-called namespace, as well as a first-class data structure that associates names with values.

If a top-level expression contains a variable declaration with the keyword local, then this variable is not available outside of this expression. A variable inside an expression does not affect global variables with the same name. An example is the declaration of local x in the begin or if block at the top level.

Keep in mind that the interactive command prompt (REPL) belongs to the global scope of the Main module.

Most of the code blocks form new local areas (for a complete list, see table above). If such a block is syntactically nested in another local area, the area it creates will be nested in all the local areas it belongs to. In turn, these areas are eventually nested in the global area of the module in which the code is calculated. Variables from external areas are visible in any internal area they contain (that is, they can be read and written to it), unless a local variable with the same name "obscures" the external one. This is true even if the external local variable is declared after the internal block (that is, later in the program text). When we say that a variable exists in a particular area, we mean that a variable with this name exists in any of the areas in which the current area is nested, or in the current area itself.

In some programming languages, variables must be explicitly declared before they can be used. In Julia, explicit declaration is also possible: if you write local x in any local scope, a new local variable will be declared in it, regardless of whether there is already a variable named x in the external scope. However, declaring each new variable in this way is tedious, so in Julia, as in many other languages, when assigning a value to a previously unknown variable, this variable is declared implicitly. If the current scope is global, then the new variable will be global. If the current area is local, then the new variable will be local to the most deeply nested local area and accessible only within it, but not from the outside. When assigning a value to an existing local variable, it is always the local variable that changes: you can only shade a local variable by explicitly declaring a new local variable in a nested scope using the keyword local. In particular, this applies to variables that are assigned values in internal functions, which may be unexpected for Python developers. In this language, an assignment in an internal function results in the creation of a new local variable, unless the variable is explicitly declared as non-local.

In general, such a mechanism is quite natural to understand, but, like many natural phenomena, it has its own subtleties that are not obvious at first glance.

When the expression x = <value> is used in the local scope, its value is determined in Julia according to the following rules, taking into account where the assignment expression is located and what x already refers to in this part of the code.

As you can see, in non-interactive contexts, the rules for strict and non-strict scopes are the same, except that if a global variable is obscured by an implicit local variable (i.e., not declared as local x), a warning is displayed. In interactive contexts, more complex rules apply for convenience. They will be discussed in more detail in further examples.

Now that you know the rules, let’s look at some examples. It is assumed that each example is executed in a new REPL session, so that in each code fragment, values are assigned only to global variables in this block.

Let’s start with a simple and clear situation - assignments inside a strict scope, in this case inside the body of a function, when a local variable with that name does not yet exist.:

Within the greet function, the assignment x = "hello" creates a new local variable x in the function scope. In this case, two facts are important: the assignment takes place in the local area, and the local variable x does not exist yet. Since x is a local variable, it doesn’t matter if there is a global variable named x'. Here, for example, we perform the assignment `x = 123 before defining and calling `greet'.

Since the variable x in greet is local, calling greet does not affect the value of the global variable x (and it does not matter if it exists). According to the strict scope rule, the existence of a global variable named x is ignored: the assignment of a value to the variable x in the strict scope occurs at the local level (unless the variable x is declared global).

In the next obvious situation that we will consider, a local variable named x already exists. In this case, the operator x = <value> always assigns a value to this existing local variable `x'. This is true regardless of whether the assignment occurs in the same local scope, in an internal local scope in the body of the same function, or in the body of a function nested in another function, which is also known as https://en.wikipedia.org/wiki/Closure_ (computer_programming)[closing].

For example, we use the sum_to function, which calculates the sum of integers from one to `n'.

As in the previous example, the first assignment of the variable s at the beginning of the function sum_to leads to the declaration of a new local variable s in the body of the function. The 'for` loop has its own internal local scope within the function scope. In the place where the assignment s = s + i occurs, the local variable s already exists, so the assignment causes the value of the existing variable s to change, rather than creating a new local variable. You can check this by calling `sum_to' in the REPL.

Since the variable s is local to the function sum_to, calling the function does not affect the global variable s. In addition, you can see that the expression s = s + i in the for loop modifies the same variable s that was created as a result of initializing s = 0, since we get the correct sum of 55 for integers from 1 to 10.

Let’s focus a little on the fact that the for loop has its own scope, and write a slightly more detailed version of the function, which we’ll call sum_to_def'. In it, the sum of `s + i is stored in the variable t before changing s.

This version returns s as before, but also uses the macro @isdefined to return a boolean value indicating whether there is a local variable named t defined in the external local scope of the function. As can be seen from the result, the variable t is not defined outside the body of the for loop. The reason again lies in the strict domain rule.: since the assignment of a value to the variable t occurs inside a function that introduces a strict scope, it leads to the creation of a new local variable t in the local scope where it appears, that is, inside the body of the loop. Even if there was a global variable named t, there would be no difference — the strict scope rule is not affected by the contents of the global scope.

Note that the local area of the body of the for loop does not differ from the local area of the internal function. This means that this example could have been rewritten differently by implementing the body of the loop as a call to an internal auxiliary function. The behavior would not have changed.

This example illustrates a couple of important points.

This scheme means that code can usually be transferred to or from an internal function without changing its meaning, which simplifies the use of a number of standard idioms in a language that supports closures (see the section on do blocks).

Let’s move on to a number of more confusing cases where the lax domain rule applies. To do this, we will extract the bodies of the greet and sum_to_def functions into the context of a non-strict scope. First, let’s put the body of the greet function in the for loop, which forms a non-strict scope, and execute it in the REPL.

Since the global variable x is not defined at the time of execution of the for loop, the first provision of the rule applies for a non-strict scope and the variable x is created as a local for the for loop. Therefore, after the loop is executed, the global variable x remains undefined. Next, let’s extract the body of the function sum_to_def into the global scope and fix its argument as `n = 10'.

What does this code do? Hint: This is a trick question. The correct answer is that it all depends on the circumstances. If this code is entered interactively, it is executed in the same way as in the function body. However, if the code is executed from a file, an ambiguity warning is displayed and the error "variable not defined" occurs. Let’s check how it works in the REPL first.

In REPL, execution in the function body is simulated by determining whether an assignment within a loop results in changing the value of a global variable or creating a new local variable based on whether a global variable with that name is defined. If a global variable with that name exists, the assignment causes it to be changed. If there is no global variable, a new local variable is created as a result of the assignment. This example demonstrates both cases.

The second fact explains why the value of the global variable s changes as a result of the execution of the loop, and the first is why the variable t is still undefined after the execution of the loop. Now let’s try to execute the same code as if it were contained in a file.

Here we use the function include_string to calculate the code' as the file content. You could also save the `code to a file, and then call include for that file — the result would be the same. As you can see, the code in this case is executed in a completely different way than in the REPL. Let’s figure out what’s going on here.

This example demonstrates a number of important aspects related to scopes: within a scope, each variable can have only one value, which does not depend on the order of expressions. The presence of the expression s = t in the loop makes the variable s local to it. This means that it is also local when used on the right side of the expression t = s + i, although this expression is evaluated first. One might think that the s in the first line of the loop would be a global variable, and the `s' in the second line would be a local one, but this is impossible, since these two lines are in the same block of the scope, and within a certain scope each variable can have only one meaning.

We have reviewed all the rules for local areas, but before concluding this section, it is worth saying a few words about why a non-strict area acts differently in interactive and non-interactive contexts. Two obvious questions arise.

In versions of Julia up to and including 0.6, all global scopes worked as they do now in REPL: when the assignment of x = <value> occurred in a loop (either in the try/catch block or in the struct body), but outside the function body (either in the let block or inclusion), the decision on whether the variable x should be local to the loop was made depending on the presence of a global variable named `x'. The advantage of this approach is that it is intuitive and convenient, as it is as similar as possible to the behavior inside the function body. In particular, it makes it easy to transfer code from the function body to the REPL and vice versa when debugging the function. But there are also disadvantages. Firstly, this approach is difficult to explain and understand: it often confused users and caused complaints. Quite fair. Secondly, and more importantly, it creates difficulties when writing large-scale programs. In a small piece of code like the following, it’s not difficult to understand what’s going on.

Obviously, the goal is to change the existing global variable `s'. What else could it mean? However, in reality, the code is not always so short and clear. For example, in real programs, you can often find this:

It’s not so easy to figure out what’s going on here. Since x + "hello" will cause a method error, it seems likely that the intention was to make the variable x local to the 'for` loop. However, based on the values of the execution time and existing methods, it is impossible to determine the scope of variables. The behavior adopted in versions of Julia up to and including 0.6 was especially dangerous for the following reason: someone could first write a for loop, and it worked fine, but then someone else could add a new global variable in a completely different place, possibly in a different file, and the meaning of the code changed. It either just started to fail, or, even worse, it was executed, but with the wrong result. In well-designed programming languages, this effect https://en.wikipedia.org/wiki/Action_at_a_distance_ (computer_programming)[creepy ranged attacks] should not be allowed.

Therefore, in Julia 1.0, we simplified the rules regarding scopes: in any local scope, assigning a value to a name that is not yet a local variable leads to the creation of a new local variable. As a result, the concept of a non-strict area has completely disappeared, which made it possible to prevent possible negative effects of long-range action. We have identified and eliminated many errors that have become our punishment for abandoning non-strict areas. And finally, they could rest on their laurels! But no, it’s not that simple. After all, I often had to do this now.:

Do you see the global annotation? It’s horrible. Of course, this state of affairs could not be tolerated. But seriously, the mandatory use of global in such top-level code is fraught with two main problems.

Starting with Julia 1.5, this code works without the global annotation in interactive contexts such as REPL or Jupyter notebooks (as in Julia 0.6), and in files and other non-interactive contexts, such an unambiguous warning is displayed.

This solves both problems and preserves the advantages of writing large-scale programs implemented in version 1.0: global variables do not have a hidden effect on the meaning of deleted code; debugging by copying to REPL works, and novice developers have no problems; when someone forgets to add the global annotation or accidentally obscures an existing global variable. local in a non-strict area, a clear warning is issued.

An important feature of this approach is that the code that runs in the file without displaying a warning will work the same way in a new REPL session. Conversely, if, after saving the code from the REPL session in a file, it is executed differently than in the REPL, a warning will be received.

Variables are often used to assign names to certain immutable values. Values for such variables are assigned only once. You can use a keyword to inform the compiler about this assignment. const.

Multiple variables can be declared in a single const statement.

The declaration const should only be used in the global scope in relation to global variables. It is difficult for the compiler to optimize code with global variables, since their values (or even types) can change at any moment. If the global variable does not change, declaring const solves this performance problem.

The situation is different with local constants. The compiler can automatically determine if a local variable is a constant, so you don’t need to declare local constants. Moreover, this feature is not supported yet.

Special top-level assignments, such as those performed by the keywords function and struct, are constant by default.

Note that const only affects the binding of a variable; a variable can be bound to a mutable object (for example, an array) that can still be modified. In addition, when trying to assign a value to a variable declared as a constant, the following scenarios are possible.

The last rule applies to immutable objects, even if the binding of the variable changes, for example:

However, for mutable objects, the warning is displayed as usual.

Please note: although it is sometimes possible to change the value of the const variable, it is strongly discouraged to do so. This feature is intended solely for convenience when working interactively. Changing constants can lead to various problems or unexpected results. For example, if a method refers to a constant and has already been compiled before changing it, the old value may be used.

Global bindings can be declared not only as having a constant value, but also as having a constant type. This can be done without assigning an actual value using the global x' syntax.::T or when assigned as `x::T = 123'.

For any assignment of a value to a global variable, Julia first tries to convert it to the appropriate type using the function convert:

The type does not have to be specific, but annotations with abstract types usually do not provide much performance benefit.

After assigning a value to a global variable or setting its type, you cannot change the binding type.