Understanding while loop UndedVarError and scope

General Usage
1

REPL, Julia v1.0.1:

julia> a=1; 

julia> while true; print(a);          break; end
1

julia> while true; a=2;               break; end

julia> while true; a=2; print(a);     break; end
2

julia> while true; print(a); a=2;     break; end

ERROR: UndefVarError: a not defined
Stacktrace:
 [1] top-level scope at .\REPL[4]:1 [inlined]
 [2] top-level scope at .\none:0

I got some explanations here https://github.com/JuliaLang/julia/issues/29313#issuecomment-431618955
but I’m still very confused.

  1. It’s obvious that the wording of the error is wrong ( a is defined there).
  2. In 1st “while”, “print” can see that “a” is 1; in the 3rd “while”, “print” can see that “a” is 2; while in the 4th “while”, it can see neither!

So I welcome any other explanations.
Also, I’m curious whether this is confusing just to me, or to other people as well?

2

So the rule is that you need to specify global a to assign values to globals inside loops
The first while simply reads the global, the second and third use a local with a defined value, and the last wants to use variable a as a local, but there was no value assigned to it yet

3

From what I can see, there was: I wrote “a=2”, just like in the previous 2 loops.

4

Yes, but you wrote if after print(a). There are two fairly simple things going on here:

  1. Having a = ... anywhere in a scope makes a local.
  2. If you access a variable before it has been assigned, it’s an undef error.

Evaluation order does not matter for 1—it’s purely syntactic. Evaluation order does matter for 2.

1 Like
5

That shines light, thanks.
I had thought Julia, as a dynamic language, would do everything at run time, in a top-down fashion. But it turns out it determines locality of variables kind of at compile time, but the actual evaluation at run time. (Of course it’s more complicated , as it’s JIT compiled…)
Which makes it seem partially blind in this case, where it can tell that a is made local by a=... but not the actual value of a so that to tell print to print 2.

Overall, I think this makes the behavior complicated, for most of users, compared to other languages.

6

I’m confused by why you expect a to have a value before you’ve assigned to it.

7 
julia> a=1; 

julia> while true; print(a);          break; end
1

julia> while true; q=2;               break; end

julia> while true; q=2; print(q);     break; end
2

julia> while true; print(q); q=2;     break; end

is an equivalent version of the code in OP.

8

I expected a to have a value for 2 reasons:

  1. a=1 present before the while loop. while loop body introducing by default a local scope is a strange (to say the least) idea to me
  2. once Julia can tell a is made local, even though a=2 occurs after print(a), somehow I expected it to also “see” the value on the other side of = in a=2.

I no longer hold the 2nd opinion (after your clarification of just syntactic determination of local scope.)
I still hold 1st opinion though, quite strongly. I will probably elaborate in another post, in “Development” section.

9

Not at all; my version illustrates the conflict between a local and global variable with same name, and user confusion it creates. Your version is not surprising at all, IMO.

10

The two versions are semantically equivalent. Your thread title was “Understanding while loop UndedVarError and scope”, my example was there to help you do that.

1 Like
11

Thank you. Now I see what you mean: they are semantically equivalent for the computer. With my reply above to you “Not quite…” I meant they are not equivalent from the user perspective/expectation.

12

I think you’re going to find this very helpful in your research. There’s no need for duplication of that topic.

1 Like
13

ONE MORE QUESTION HERE

I’ve been told repeatedly that An explicit global is needed to change a global variable.
Then why this works (again Repl, v 1.01) ?

julia> v=[0 0];
julia> while true; v[1]=1; break; end
julia> v
1×2 Array{Int32,2}:
1  0
14

global is needed to rebind a variable which is a completely different thing from mutating a container.

v[1] = 1 is just pretty syntax for setindex!(v, 1, 1).

15

OK.
But the effect is exactly the same as v=[1 0] !

I thought the intent of all these globals was to prevent modifying stuff in global scope unintentionally
From https://docs.julialang.org/en/v1/manual/variables-and-scoping/:

Avoiding changing the value of global variables is considered by many to be a programming best-practice.

This is all… overcomplicated.

16

No, it is definitely not.

Case 1, using v[1] = 1

v = [0 0]
x = v
v[1] = 1
x

printing x now shows [1 0].

Case 2, using v = [1 0]

v = [0 0]
x = v
v = [1 0]
x

printing x now shows [0 0].

Scoping is about what value (or object) a particular symbol is bound to. Assignment changes that. Mutation does not.

17

I don’t understand how your explanation is relevant to what I was saying (I don’t blame you).

I knew that in Julia assignment can bind several names to the same object, and mutating the object via one name results in all names pointing now to the new object

But in the context I talked about, I used only 1 name, v, and was stating that allowing v[1]=1 inside while to mutate global v would be the same as if Julia allowing direct v = [1 0] inside that loop to modify that same global v.

Scoping is about what value (or object) a particular symbol is bound to. Assignment changes that. Mutation does not.

With s =[0 0] , then does not s[1]=1 result in now symbol s being bound to a new object, [1 0], as compared to [0 0]?

(I don’t mean the internal implementation details, but the end result)

18

No, it means that the object s has been modified but it is the same object.

julia> s = [0 1];

julia> pointer_from_objref(s)
Ptr{Nothing} @0x000000010e6324d0

julia> s[1] = 1;

julia> pointer_from_objref(s) # the same as before
Ptr{Nothing} @0x000000010e6324d0

julia> s = [1 1];

julia> pointer_from_objref(s) # different, new object
Ptr{Nothing} @0x000000010ecf55d0
19

That’s sounds like a logical self-contradiction to me :face_with_monocle:

You are showing that with mutation, the address of the object remains the same: but then you interpret this to mean that the object stays the same as well.

I “prove” the “same-ness” of the 2 objects like this :slight_smile:

s=[0 0]; s[1] = 1;
s == [1 0]
true
s = [1 0];
s == [1 0]
true
20

It isn’t though. There is a difference between repainting a house and building a new identical house with a new color. As a case where this would matter, burning down the new identical house is likely ok while burning down the repainted house would likely get you in trouble with the people who own it.

Scope has to do with the bindings of symbols to objects, not the content of the objects.

Having different definitions than everyone else means that there will be trouble when you communicate with other people. I’ve already shown you where your definition of “same-ness” and two objects being identical matters.

3 Likes