Understanding while loop UndedVarError and scope

[Vic]

@kristoffer.carlsson

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.

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.
(Variables · The Julia Language )
An array is a collection of objects stored in a multi-dimensional grid. In the most general case, an array may contain objects of type Any .
(Single- and multi-dimensional Arrays · The Julia Language )

On the other hand, how to compare objects can be defined in different ways: ==, ===, (others?..)

[kristoffer.carlsson]

@Vic

Which even more supports my point that if you allow v[1]=1 inside loops, then you should allow v = [1 1] as well.

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.

[Vic]

It’s … both. Thanks!

[StefanKarpinski]

@Vic

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]
true

You’re using the wrong equality operator. Try it again with === and you’ll be doing it the right way.

[Vic]

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

[StefanKarpinski]

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.

http://home.pipeline.com/~hbaker1/ObjectIdentity.html

[Vic]

Actually, that reply Understanding while loop UndedVarError and scope - #19 by Vic 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 - #19 by Vic .

[theferrit32]

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.