Variables, bindings and Unicode names

A calibration script keeps a backup of three sensor offsets with saved = offsets, zeroes the first entry of the backup, and the original changes with it: offsets now starts with 0.0. Nothing was copied. In Julia, = gives a value one more name, and every name reaches the same vector.

Each behaviour below is a run recorded on Julia 1.13.1: what = and a function call do with your data, how to read a value’s type with typeof and test it with isa, how to type names such as α, x̄ and Δx so that a formula reads as it is printed, and when a constant or a typed global is worth declaring. One of these behaviours is different on the 1.10 LTS, so its run there is shown too.

Assignment gives a value another name, and never copies it

Here is the backup that went wrong, then one that works, and a case that catches careful readers too: a vector whose elements are vectors.

# Calibration offsets of three temperature sensors, in °C.
offsets = [0.5, -0.25, 0.75]
saved = offsets          # a second name for the same vector
saved[1] = 0.0           # writes into that vector
println("offsets = ", offsets, ", saved === offsets: ", saved === offsets)

saved = copy(offsets)    # a new vector with the same numbers
saved[1] = 9.0
println("offsets = ", offsets, ", saved = ", saved, ", saved === offsets: ", saved === offsets)

# copy makes a new outer vector, but the inner vectors are shared.
runs = [[20.25, 20.5], [19.75, 20.0]]
shallow = copy(runs)
deep = deepcopy(runs)
shallow[1][1] = -99.0
deep[2][1] = 0.0
println("runs = ", runs)
println("deep = ", deep)

from session import files, run

# Two names for one vector, a copy, a rebinding, then copy against deepcopy on a vector of vectors.
files("aliasing.jl")
run("""
julia aliasing.jl
""")

$ julia aliasing.jl
offsets = [0.0, -0.25, 0.75], saved === offsets: true
offsets = [0.0, -0.25, 0.75], saved = [9.0, -0.25, 0.75], saved === offsets: false
runs = [[-99.0, 20.5], [19.75, 20.0]]
deep = [[20.25, 20.5], [0.0, 20.0]]

The first line of output shows the problem: offsets starts with 0.0 although the program wrote only to saved, and saved === offsets is true. === asks whether two values are identical in the sense that no program could tell them apart, and for a vector that means one and the same object. The manual describes b = a as binding the name b to the same array, and that is all a bindingbinding: A name attached to a value. Assignment with = creates or moves a binding and never copies the value, so several names can be bound to one object. is: a name attached to a value. Step through the program up to its vector of vectors, and watch the arrows rather than the numbers:

Writing into a vector, as saved[1] = 0.0 does, is mutationmutation: Changing an object itself, as v[1] = 0 writes into a vector. Every name bound to that object sees the change; binding a name to another value is not mutation.: it changes the object, so every name bound to it sees the change. Assigning to a name, saved = copy(offsets), only moves that name, and no object changes. copy built a second vector, so the later saved[1] = 9.0 left offsets alone and === turned false.

copy makes a shallow copyshallow copy: A copy of a container that holds the same element objects as the original. copy of a vector of vectors makes a new outer vector that shares the inner ones.: its documentation says the outer structure is copied but not all internal values. The last two lines of the run show what that means for runs, a vector holding two vectors. shallow = copy(runs) is a new outer vector that holds the same two inner vectors, so shallow[1][1] = -99.0 changed runs too. deepcopy(runs) is a deep copydeep copy: A copy made recursively, all the way down, so that it shares no object with the original. Julia's deepcopy makes one., copied all the way down, so writing into it left runs as it was.

A function gets the caller’s object, not a copy

Calling a function binds its arguments the same way: the name inside the function is bound to the object the caller passed. A function that writes into its argument therefore changes the caller’s data, and Julia’s style guide asks for a warning in the name: a function that changes at least one of its arguments ends in !, as sort! does beside sort. This file defines both kinds for sensor readings, and a third function that only looks as if it clears its argument:

"Subtract `offset` from every reading in `raw`, in place, and return `raw`."
function calibrate!(raw, offset)
    for i in eachindex(raw)
        raw[i] -= offset
    end
    return raw
end

"Return a calibrated copy of `raw`, and leave `raw` as it was."
calibrate(raw, offset) = calibrate!(copy(raw), offset)

"Looks as if it clears `raw`, but it only rebinds its own name."
function reset_readings(raw)
    raw = zeros(length(raw))
    return raw
end

readings = [20.5, 21.0, 19.75]
fixed = calibrate(readings, 0.25)
println("calibrate:      ", readings, " → ", fixed)
calibrate!(readings, 0.25)
println("calibrate!:     ", readings)
reset_readings(readings)
println("reset_readings: ", readings)

from session import files, run

# A function receives the caller's vector itself: calibrate! changes it, calibrate works on a copy, and assigning
# to the argument's name inside a function changes nothing outside it.
files("calibrate.jl")
run("""
julia calibrate.jl
""")

$ julia calibrate.jl
calibrate:      [20.5, 21.0, 19.75] → [20.25, 20.75, 19.5]
calibrate!:     [20.25, 20.75, 19.5]
reset_readings: [20.25, 20.75, 19.5]

calibrate returned new numbers and left readings as it was, because it runs calibrate! on copy(raw). calibrate! changed readings itself, which is what its name promised. reset_readings changed nothing, although it assigns zeros to raw. Step through the two calls that reach the vector:

Building calibrate as calibrate! on a copy is a common Julia pattern: the version that works in place does the arithmetic and saves the memory of a new vector, and the copying version is one line on top of it. The ! is a convention, not a rule the language checks, so it protects callers only if every function that changes an argument follows it. The other naming conventions of the manual and the style guide, with examples from Base and this lesson:

Values carry types, and names do not

Every value knows its type, and typeof asks for it. Here are ten values, the chain of types above Int64, and five tests with isa:

# Every value knows its type; typeof asks for it.
for x in (1, 1.0, 1//2, 2.0 + 3im, 0xff, big(10)^20, true, 'α', "α", nothing)
    println(rpad(repr(x), 24), typeof(x))
end

# isa asks whether a value belongs to a type, or to any type above its own.
using InteractiveUtils   # supertypes, like subtypes, is a REPL helper that a script loads
println(supertypes(Int64))
println(1 isa Int64, " ", 1 isa Integer, " ", 1 isa Real, " ", 1.0 isa Integer, " ", true isa Integer)

# A name has no type of its own: it can be bound to an Int64, then to a String.
x = 1
x = "one"
println(typeof(x))

from session import files, run

# typeof on ten values, the supertypes of Int64, five isa tests, and one name rebound to another type.
files("types.jl")
run("""
julia types.jl
""")

$ julia types.jl
1                       Int64
1.0                     Float64
1//2                    Rational{Int64}
2.0 + 3.0im             ComplexF64
0xff                    UInt8
100000000000000000000   BigInt
true                    Bool
'α'                     Char
"α"                     String
nothing                 Nothing
(Int64, Signed, Integer, Real, Number, Any)
true true true false true
String

1 is an Int64 and 1.0 a Float64: a decimal point changes the type. 1//2 is an exact fraction, Rational{Int64}, and 2.0 + 3im is a ComplexF64; the last lesson of this module covers both. The last line shows the other half of the rule: x was bound to an Int64 and then to a String, and Julia did not object, because an ordinary name has no type of its own.

typeof gives the value’s concrete type, the one the value itself has. The types above it, such as Integer and Real, are abstract typesA type that no value has directly, such as Integer, Real or Number. It groups concrete types like Int64 and Bool, so that isa tests and methods can treat them alike., and isa answers a wider question: is the value of this type, or of any type above its own? supertypes(Int64) printed the chain from Int64 up to Any, and every isa test is a step along such a chain:

true isa Integer was true because Bool sits under Integer, so true + true is 2. 1.0 isa Integer was false: Float64 joins the chain only at Real, even when its value is a whole number.

Unicode names are typed with a backslash and Tab

Physics and mathematics write α, x̄ and Δx, and Julia accepts such names: the manual allows Unicode names in UTF-8. To type one at the REPL, write a backslash and a LaTeX-like name, then press Tab, and the name turns into its character. ? followed by a character prints how to type it:

from session import repl

# Unicode names at the REPL: a backslash, a LaTeX-like name, then Tab, which replaces the name with its character.
# "?" followed by a character prints how to type it.
repl([
    "\\alpha\t = 0.5",
    "x\\bar\t = 2.0",
    "\\Delta\tx = 0.25",
    "\\sqrt\t16",
    "?x̄",
])

$ julia --startup-file=no -q
julia> α = 0.5
0.5

julia> x̄ = 2.0
2.0

julia> Δx = 0.25
0.25

julia> √16
4.0

help?> x̄
"x̄" can be typed by x\bar<tab>

search: x̄

  No documentation found for private binding Main.x̄.

  x̄ is of type Float64.

  Summary
  ≡≡≡≡≡≡≡

  primitive type Float64

  Supertype Hierarchy
  ≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡

  Float64 <: AbstractFloat <: Real <: Number <: Any

\alpha became α and \Delta became Δ. The bar of x̄ is a separate combining character that follows its letter, so you type x\bar and then Tab, which is what help printed; it also showed that x̄ holds a Float64. The manual notes that several Julia editing environments complete the same names. The ones numerical code meets most:

In a script the same names make a formula read the way it is printed. This one works out the kinetic energy, the momentum and the mean speed of a 160 g ball:

# A 160 g ball bowled at 38 m/s, with names written as a physics text writes them.
m = 0.160                          # mass, kg
v = 38.0                           # speed, m/s
Eₖ = m * v^2 / 2                   # kinetic energy, J        (typed E\_k Tab)
p = m * v                          # momentum, kg·m/s
speeds = [36.5, 38.0, 39.5]        # three deliveries, m/s
v̄ = sum(speeds) / length(speeds)   # mean speed               (typed v\bar Tab)
Δv = maximum(speeds) - minimum(speeds)
println("Eₖ = ", Eₖ, " J, p = ", p, " kg·m/s")
println("v̄ = ", v̄, " m/s, Δv = ", Δv, " m/s")

# Operators written as symbols are ordinary functions with ordinary names.
println(√(2Eₖ / m) ≈ v, " ", 38.0 ∈ speeds, " ", 7 ÷ 2, " ", ≈(0.1 + 0.2, 0.3))

The symbols in its last line are functions with Unicode names: √ is sqrt, ∈ is in, ÷ is integer division div, and ≈ is isapprox, which the last call uses with two arguments like any other function. The run printed Eₖ = 115.52 J and confirmed that √(2Eₖ/m) gives back the 38 m/s:

from session import files, run

# Unicode names in a script, then numeric literal coefficients and the one form that is not a product.
files("greek_physics.jl", "coefficients.jl")
run("""
julia greek_physics.jl
!julia coefficients.jl
""")

$ julia greek_physics.jl
Eₖ = 115.52 J, p = 6.08 kg·m/s
v̄ = 38.0 m/s, Δv = 3.0 m/s
true true 3 true
$ julia coefficients.jl
2x = 6, 2(x + 1) = 8, 2x^2 = 18, 2^2x = 64, 1/2x = 0.16666666666666666
ERROR: LoadError: MethodError: objects of type Int64 are not callable.
In case you did not try calling it explicitly, check if a Int64 has been passed as an argument to a method that expects a callable instead.
The object of type `Int64` exists, but no method is defined for this combination of argument types when trying to treat it as a callable object.
Maybe you forgot to use an operator such as *, ^, %, / etc. ?
Stacktrace:
 [1] top-level scope
   @ ~/demo/coefficients.jl:3
 [2] include(mod::Module, _path::String)
   @ Base ./Base.jl:309
 [3] exec_options(opts::Base.JLOptions)
   @ Base ./client.jl:344
 [4] _start()
   @ Base ./client.jl:577
in expression starting at ~/demo/coefficients.jl:3
[exit status 1]

A number before a name multiplies it

The second file of that run shows a numeric literal coefficientnumeric literal coefficient: A number written directly before a name or a parenthesis, as in 2x or 3(x + 1), which multiplies it. It binds more tightly than * and /, so 1/2x means 1/(2x).: with x = 3, 2x is 6 and 2(x + 1) is 8, as on paper. The manual gives it a higher precedence than * and /, so 1/2x is 1/(2x), 0.1666…, not 1.5. With ^ it acts like a minus sign in front: 2x^2 is 2(x²) = 18, while in an exponent 2^2x is 2^(2x) = 64. One form is not a product: a name followed by parentheses, x(x + 1), is a call of x, and the run stopped with a MethodError saying that an Int64 is not callable.

Characters that look alike

Two characters can look the same and still be different code points; Unicode’s security standard, UTS #39, calls them confusables. The manual lists a few pairs that Julia treats as one character, among them the micro sign µ and the Greek letter μ. Most look-alikes stay apart, and this file, whose comments say which letter is which, shows both cases:

# Two pairs of letters that look alike. The first pair is one name to Julia, the second is two.
µ = 2.5e-6            # typed with the micro sign, U+00B5
println("μ = ", μ)     # read back with the Greek letter mu, U+03BC

а = 1.0               # this а is Cyrillic, U+0430
println(codepoint('а'), " is not ", codepoint('a'))
println(a)            # this a is Latin, U+0061, and was never assigned

from session import files, run

# Julia reads the micro sign as the Greek letter mu, so both spell one name; a Cyrillic letter stays a name of its own.
files("lookalikes.jl")
run("""
!julia lookalikes.jl
""")

$ julia lookalikes.jl
μ = 2.5e-6
1072 is not 97
ERROR: LoadError: UndefVarError: `a` not defined in `Main`
Suggestion: check for spelling errors or missing imports.
Stacktrace:
 [1] top-level scope
   @ ~/demo/lookalikes.jl:7
 [2] include(mod::Module, _path::String)
   @ Base ./Base.jl:309
 [3] exec_options(opts::Base.JLOptions)
   @ Base ./client.jl:344
 [4] _start()
   @ Base ./client.jl:577
in expression starting at ~/demo/lookalikes.jl:7
[exit status 1]

μ printed the value assigned through µ: one name. But а = 1.0, with a Cyrillic а, created a name that the Latin a of the last line does not reach, so the run stopped with UndefVarError although every line looks right. In code that others read, keep to letters they can tell apart, and when a name seems to vanish, look at its code points.

const fixes a name’s value, and a typed global fixes its type

An ordinary global can be bound to any value of any type at any moment. Two declarations promise less. A const globalconst global: A global name declared with const. It may not be assigned again with =, which lets the compiler rely on its value and type; declaring it again is well defined from Julia 1.12. may not be assigned again with =, and a typed globaltyped global: A global declared with a type, as in g::Float64 = 9.81, available since Julia 1.8. Every value assigned to it is converted to that type, or the assignment fails. keeps one type. Constants come with a version story. This file computes how long a fall of 20 m takes with gravity rounded to 9.81, then declares the constant again with its standard value, 9.80665, and calls the same function; a second file tries plain assignment instead:

# Standard gravity, first rounded, then corrected by declaring the constant again.
const GRAVITY = 9.81                 # m/s²
fall_time(h) = sqrt(2h / GRAVITY)    # seconds to fall h metres, from rest
before = fall_time(20.0)             # compiled and run with the first value

const GRAVITY = 9.80665              # the exact standard value
after = fall_time(20.0)              # the same function, called again
println("before: ", before)
println("after:  ", after)
println("fresh:  ", sqrt(2 * 20.0 / GRAVITY))

# Plain assignment to a constant, without const, is refused.
const GRAVITY = 9.81
GRAVITY = 10

from session import files, run, use

# The same files on the current release and on the 1.10 LTS: redefining a constant with const is well defined from
# 1.12 on, and plain assignment to a constant is refused on both.
files("const_versions.jl", "const_assign.jl")
run("""
julia const_versions.jl
!julia const_assign.jl
""")
use("1.10.12")
run("""
julia const_versions.jl
!julia const_assign.jl
""")

$ julia const_versions.jl
before: 2.019275109384609
after:  2.0196199771025523
fresh:  2.0196199771025523
$ julia const_assign.jl
ERROR: LoadError: invalid assignment to constant Main.GRAVITY. This redefinition may be permitted using the `const` keyword.
Stacktrace:
 [1] top-level scope
   @ ~/demo/const_assign.jl:3
 [2] include(mod::Module, _path::String)
   @ Base ./Base.jl:309
 [3] exec_options(opts::Base.JLOptions)
   @ Base ./client.jl:344
 [4] _start()
   @ Base ./client.jl:577
in expression starting at ~/demo/const_assign.jl:3
[exit status 1]
$ julia const_versions.jl
WARNING: redefinition of constant Main.GRAVITY. This may fail, cause incorrect answers, or produce other errors.
before: 2.019275109384609
after:  2.019275109384609
fresh:  2.0196199771025523
$ julia const_assign.jl
ERROR: LoadError: invalid redefinition of constant Main.GRAVITY
Stacktrace:
 [1] top-level scope
   @ ~/demo/const_assign.jl:3
in expression starting at ~/demo/const_assign.jl:3
[exit status 1]

On 1.13.1 the second call used the new value: after equals a fresh computation, 2.0196199771025523 s. On 1.10.12 Julia warned that the redefinition may cause incorrect answers, and then gave one: fall_time had been compiled with 9.81 built in, so after repeated the old 2.019275109384609 while a fresh computation printed the new number. From 1.12 on, the release notes say, redefining a constant is well defined and follows world ageworld age: A counter that grows with every change to Julia's methods and bindings. Running code sees the definitions of the world it started in, so a new method reaches it only after it returns or through invokelatest. More in “Notebooks, editors and the Revise workflow”, as new methods do. Plain assignment without const, the GRAVITY = 10 of const_assign.jl, stopped with an error on both versions. Walk through the four releases that matter here:

A typed global, which Julia has had since 1.8, is declared with its type. Every later assignment is converted to that type, or fails:

# A typed global keeps one type: every value assigned to it is converted to that type.
g::Float64 = 9.81
g = 10                 # an Int64, converted to 10.0
println(g, " ", typeof(g))
g = "ten"              # no conversion from a String to a Float64 exists

from session import files, run

# A global declared as Float64 accepts an integer (converted) and refuses a string.
files("typed_global.jl")
run("""
!julia typed_global.jl
""")

$ julia typed_global.jl
10.0 Float64
ERROR: LoadError: MethodError: Cannot `convert` an object of type String to an object of type Float64
The function `convert` exists, but no method is defined for this combination of argument types.

Closest candidates are:
  convert(::Type{T}, !Matched::T) where T<:Number
   @ Base number.jl:6
  convert(::Type{T}, !Matched::Number) where T<:Number
   @ Base number.jl:7
  convert(::Type{T}, !Matched::T) where T
   @ Base Base_compiler.jl:136
  ...

Stacktrace:
 [1] top-level scope
   @ ~/demo/typed_global.jl:5
 [2] include(mod::Module, _path::String)
   @ Base ./Base.jl:309
 [3] exec_options(opts::Base.JLOptions)
   @ Base ./client.jl:344
 [4] _start()
   @ Base ./client.jl:577
in expression starting at ~/demo/typed_global.jl:5
[exit status 1]

Why declare either one? The performance tips explain that an untyped global may change its value, and with it its type, at any point, so the compiler cannot rely on either. This program sums the same million readings from an ordinary global, a constant, a typed global and an argument:

# The same sum over a million readings, read from three kinds of global and from an argument.
readings = fill(0.5, 10^6)                   # an ordinary global: any value may replace it
const READINGS = readings                    # a constant binding to the same vector
typed_readings::Vector{Float64} = readings   # a typed global

function sum_global()
    s = 0.0
    for r in readings
        s += r
    end
    return s
end
function sum_const()
    s = 0.0
    for r in READINGS
        s += r
    end
    return s
end
function sum_typed()
    s = 0.0
    for r in typed_readings
        s += r
    end
    return s
end
function sum_argument(xs)
    s = 0.0
    for r in xs
        s += r
    end
    return s
end

"Bytes allocated by one call f(args...), and the fastest of five calls in milliseconds."
function measure(f, args...)
    f(args...)                                         # the first call compiles
    bytes = @allocated f(args...)
    # Base.donotdelete stops the compiler from skipping a sum whose result is never used.
    best = minimum(@elapsed(Base.donotdelete(f(args...))) for _ in 1:5)
    return bytes, round(best * 1000; digits = 2)
end

for (label, f, args) in (("ordinary global", sum_global, ()), ("const global", sum_const, ()),
                         ("typed global", sum_typed, ()), ("argument", sum_argument, (readings,)))
    bytes, ms = measure(f, args...)
    println(rpad(label, 17), f(args...), "  ", lpad(bytes, 8), " bytes  ", ms, " ms")
end

from session import files, run

# Bytes allocated and the fastest of five runs for each kind of global. The times depend on the computer and on what
# else it is doing; the bytes do not.
files("global_speed.jl")
run("""
julia global_speed.jl
""")

$ julia global_speed.jl
ordinary global  500000.0  79991840 bytes  113.46 ms
const global     500000.0         0 bytes  0.9 ms
typed global     500000.0         0 bytes  0.9 ms
argument         500000.0         0 bytes  0.9 ms

Reading the ordinary global allocated 79,991,840 bytes, about 80 bytes for each reading, and took 113.46 ms in this run. The constant, the typed global and the argument each allocated nothing and took 0.9 ms, about 126 times less. The tips name the fix that needs no global at all: pass the data to the function as an argument.

Practise: names, types and globals

These questions replay the runs of this lesson. The idea you know least is asked first, and each answer says why it holds or what it misses:

Interview questions

Warm-up (fresher to 2–5 years): what does b = a do when a is a vector, and how do you get a copy you can change on its own?

b = a copies nothing: it binds the name b to the vector that a already names, so both names reach one object and b === a is true. Writing into it through either name, as in b[1] = 0, changes what the other name sees, while assigning to a name, b = [9, 9], only moves that name. For an independent copy of a vector of numbers, use b = copy(a). copy is shallow, though: for a vector of vectors it makes a new outer vector that still shares the inner ones, so a write into b[1][1] reaches a. deepcopy(a) copies everything recursively and shares nothing. Function arguments follow the same rule, which is why a function that writes into its argument should end in !.

Two harder questions follow, about a function that damaged its input and about a script slowed by its globals. Note your answer first, then open each first step:

Key takeaways

• = binds a name to a value and never copies it, so a write into a vector is seen through every name bound to it; copy makes a shallow copy and deepcopy a fully independent one.
• A function’s argument is bound to the caller’s object, so a function that writes into it changes the caller’s data, and by convention its name ends in !.
• Values carry types and ordinary names do not: typeof gives a value’s concrete type, and isa also accepts every abstract type above it, such as Integer or Real.
• Unicode names are typed as a backslash, a LaTeX-like name and Tab; a number written before a name multiplies it, and letters that look alike can be different names.
• A constant fixes a global’s value and a typed global its type, which removes the allocations of an ordinary global; redefining a constant is well defined from Julia 1.12 and unreliable on 1.10.