Scope of Variables¶

Soft Local Scope¶

In a soft local scope, all variables are inherited from its parent scope unless a variable is specifically marked with the keyword local.

Soft local scopes are introduced by for-loops, while-loops, comprehensions, try-catch-finally-blocks, and let-blocks. There are some extra rules for let-blocks and for for-loops and comprehensions.

In the following example the x and y refer always to the same variables as the soft local scope inherits both read and write variables:

x,y=0,1fori=1:10x=i+y+1endjulia>x12

Within soft scopes, the global keyword is never necessary, although allowed. The only case when it would change the semantics is (currently) a syntax error:

letlocalx=2letglobalx=3endend# ERROR: syntax: `global x`: x is local variable in the enclosing scope

Hard Local Scope¶

Hard local scopes are introduced by function definitions (in all their forms), type & immutable-blocks, and macro-definitions.

In a hard local scope, all variables are inherited from its parent scope unless:

• an assignment would result in a modified global variable, or
• a variable is specifically marked with the keyword local.

Thus global variables are only inherited for reading but not for writing:

x,y=1,2function foo()x=2# assignment introduces a new localreturnx+y# y refers to the globalendjulia>foo()4julia>x1

An explicit global is needed to assign to a global variable:

x=1function foo()globalx=2endfoo()julia>x2

Note that nested functions can behave differently to functions defined in the global scope as they can modify their parent scope’s local variables:

x,y=1,2function foo()x=2# introduces a new localfunction bar()x=10# modifies the parent's xreturnx+y# y is globalendreturnbar()+x# 12 + 10 (x is modified in call of bar())endjulia>foo()22# (x,y unchanged)

The distinction between inheriting global and local variables for assignment can lead to some slight differences between functions defined in local vs. global scopes. Consider the modification of the last example by moving bar to the global scope:

x,y=1,2function bar()x=10# localreturnx+yendfunction foo()x=2# localreturnbar()+x# 12 + 2 (x is not modified)endjulia>foo()14# as x is not modified anymore.# (x,y unchanged)

Note that above subtlety does not pertain to type and macro definitions as they can only appear at the global scope. There are special scoping rules concerning the evaluation of default and keyword function arguments which are described in the Function section.

An assignment introducing a variable used inside a function, type or macro definition need not come before its inner usage:

julia>f=y->x+y(::#1) (generic function with 1 method)julia>f(3)ERROR:UndefVarError:xnotdefinedin(::##1#2)(::Int64) at ./none:1...julia>x=11julia>f(3)4

This behavior may seem slightly odd for a normal variable, but allows for named functions — which are just normal variables holding function objects — to be used before they are defined. This allows functions to be defined in whatever order is intuitive and convenient, rather than forcing bottom up ordering or requiring forward declarations, as long as they are defined by the time they are actually called. As an example, here is an inefficient, mutually recursive way to test if positive integers are even or odd:

even(n)=n==0?true:odd(n-1)odd(n)=n==0?false:even(n-1)julia>even(3)falsejulia>odd(3)true

Julia provides built-in, efficient functions to test for oddness and evenness called iseven() and isodd() so the above definitions should only be taken as examples.

Hard vs. Soft Local Scope¶

Blocks which introduce a soft local scope, such as loops, are generally used to manipulate the variables in their parent scope. Thus their default is to fully access all variables in their parent scope.

Conversely, the code inside blocks which introduce a hard local scope (function, type, and macro definitions) can be executed at any place in a program. Remotely changing the state of global variables in other modules should be done with care and thus this is an opt-in feature requiring the global keyword.

The reason to allow modifying local variables of parent scopes in nested functions is to allow constructing closures which have a private state, for instance the state variable in the following example:

letstate=0globalcountercounter()=state+=1endjulia>counter()1julia>counter()2

See also the closures in the examples in the next two sections.

Let Blocks¶

Unlike assignments to local variables, let statements allocate new variable bindings each time they run. An assignment modifies an existing value location, and let creates new locations. This difference is usually not important, and is only detectable in the case of variables that outlive their scope via closures. The let syntax accepts a comma-separated series of assignments and variable names:

letvar1=value1,var2,var3=value3codeend

The assignments are evaluated in order, with each right-hand side evaluated in the scope before the new variable on the left-hand side has been introduced. Therefore it makes sense to write something like letx=x since the two x variables are distinct and have separate storage. Here is an example where the behavior of let is needed:

Fs=Array{Any}(2)i=1whilei<=2Fs[i]=()->ii+=1endjulia>Fs[1]()3julia>Fs[2]()3

Here we create and store two closures that return variable i. However, it is always the same variable i, so the two closures behave identically. We can use let to create a new binding for i:

Fs=Array{Any}(2)i=1whilei<=2leti=iFs[i]=()->iendi+=1endjulia>Fs[1]()1julia>Fs[2]()2

Since the begin construct does not introduce a new scope, it can be useful to use a zero-argument let to just introduce a new scope block without creating any new bindings:

julia>letlocalx=1letlocalx=2endxend1

Since let introduces a new scope block, the inner local x is a different variable than the outer local x.

For Loops and Comprehensions¶

for loops and comprehensions have the following behavior: any new variables introduced in their body scopes are freshly allocated for each loop iteration. This is in contrast to while loops which reuse the variables for all iterations. Therefore these constructs are similar to while loops with let blocks inside:

Fs=Array{Any}(2)fori=1:2Fs[i]=()->iendjulia>Fs[1]()1julia>Fs[2]()2

for loops will reuse existing variables for its iteration variable:

i=0fori=1:3endi# here equal to 3

However, comprehensions do not do this, and always freshly allocate their iteration variables:

x=0[xforx=1:3]x# here still equal to 0