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.
I think you’re going to find this very helpful in your research. There’s no need for duplication of that topic.
1 Like
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 0global 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).
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.
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.
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)
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
That’s sounds like a logical self-contradiction to me 
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 
s=[0 0]; s[1] = 1;
s == [1 0]
true
s = [1 0];
s == [1 0]
trueIt 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
This means that allowing to mutate a globally defined object is more dangerous than just creating a new one. Which even more supports my point that if you allow v[1]=1 inside loops, then you should allow v = [1 1] as well.
Having different definitions than everyone else means that there will be trouble when you communicate with other people.
True. But it seems like different people have different notions of “object”, depending on their background.
Do you have a reference to the definition of “object” in Julia documentation?
I could not find one, so I use an everyday notion.
A variable, in Julia, is a name associated (or bound) to a value.
(https://docs.julialang.org/en/v1/manual/variables/ )
An array is a collection of objects stored in a multi-dimensional grid. In the most general case, an array may contain objects of typeAny.
(https://docs.julialang.org/en/v1/manual/arrays/ )
On the other hand, how to compare objects can be defined in different ways: ==, ===, (others?..)
I had the assumption here that you wanted to understand and learn how Julia scope behaved but this is more and more getting into just repeating Another possible solution to the global scope debacle so I’ll just refer to that.
1 Like
It’s … both. Thanks!
You’re using the wrong equality operator. Try it again with === and you’ll be doing it the right way.
Why would that be the right way? I mean, when I use variables, I mostly care about their values, not the addresses of those values
Because === computes “programmatic indistinguishability” which is the one true notion of object equality. Everything else is somewhat arbitrary and happens to be convenient sometimes and wrong other times.
Actually, that reply Understanding while loop UndedVarError and scope was in the context where I argued that:
One mutable object, once it has been mutated, it’s no longer “same” as before.
I meant “same” with respect to intrinsic properties (values) that changed at mutating, not identity (which is preserved, just like I’m still Vic even though this discussion has made me smarter ).
I should yet find time to read the paper you suggest.
For now, I’d say that programmatic indistinguishability (and ===) is good for judging identity, but not equality (compares values) of mutable objects.
Plus, an object preserves it’s identity, but if mutated it changes in value, so I can’t say it remains equal to itself across time.
LAST EDIT:
in retrospect, I can see how the word “same” is better suitable for talking about identity of an object, not values. English is so ambiguous! So I misunderstood @kristoffer.carlsson with my reply here Understanding while loop UndedVarError and scope . 
This post was temporarily hidden by the community for possibly being off-topic, inappropriate, or spammy.
I came across this thread while encountering a similar but slightly different issue.
I have to say this behavior is extremely confusing. The confusion being that the 1st loop example succeeds with no issues, but the 4th loop example fails. This seems inconsistent. If the variable is out of scope both of those loops should fail. However the 1st one succeeds, meaning that the code had no issue locating the variable a and reading the value, despite it supposedly being out of scope. The scoping of the variable a should not change depending on the content of the loop (other than an invocation of global). It is changing the meaning of print(a) based on there being a later write to a inside that scope. If print(a) can find the variable then a = a+1 should too.
If this succeeds: while true; print(a); break; end
Then this should also: while true; print(a); a = a + 1; break; end
Based on how many questions I’ve found regarding this behavior online, I think this decision should be re-evaluated. In my case I had a function where I changed a parameter name, so that local references to that parameter should have immediately broken the next time I called it because that variable does not exist in that local scope, however that wasn’t the case, it just silently kept “working” (silently failing) because there happened to be a global with the same name. I’m fine with the decision to have the local scope not recognize global scope variables automatically, however in the 1st case it is, and in the 4th case it is not. I think the behavior should be one way or the other.