Global scope confusion again

It appears that we have a discrepancy between how our machines behave. I have Julia version 1.0.2. running on Juno. I tried what you did and it does not work on my machine. I first ran f() and g() in the same program just like I did before. No go. Then, I ran f() and g() one by one in the REPL. No go. It throws the same error message concerning g() already having a value. Then I ran f() and g() as a single program in REPL and still no go.

Or, possibly, you are ignoring suggestions or questions that could help you solve the problem, ie

1 Like

An alternative way to debug this is to see what g is in your current session.

1 Like

:+1:Thank you guys so much for trying to help me with this. As long as I was running 0.x in Juno, I was in heaven and the books I had on Julia made things comprehensible. I think that I’m now way over my head and in the wrong world with this scoping thing because I can’t seem to conceptualize scoping properly. It seems like a genuine computer science thing, which real programmers deal with gracefully.

I think that I need to bite the bullet and start using Mathematica. It’s a shame, because Julia 0.x had a virtually zero learning curve for me, and that was truly amazing! Only Basic and Fortran have given me zero learning curves in the past, but they belong to the past millennium.

Having said that, I don’t want this to reflect badly on Julia. I just want to debug my own thinking rather than somebody else’s product.

That seems like a bit of an overreaction to a single language change. The rule is very simple: if you want to modify a global variable inside of any scope-creating construct (loops, functions, let) you need to use the global keyword. Without that, an assignment inside any scope-creating construct assigns to a local variable if one already exists, or declares a new one if none exists; in no case does it assign to a global without the global annotation. Is writing global occasionally really so taxing that it’s easier to change programming languages entirely?

Aside: Mathematica is a wonderful system but it has super broken scope behavior.

11 Likes

If I were to guess the broader point: the mental model of scoping he has in mind (that I can take almost any code and put a function around it, like you could do in v0.6) is broken, and he thinks that the new scoping rules are sufficiently perplexing that it is a signal of what else is counter-intuitive and possibly “buggy” in the language. It is not just about “writing global” occasionally, but about the inability to copy/paste code, reorganize in functions, etc. without thinking through scoping rules. This didn’t happen before, and doesn’t happen currently with jupyter. As you know, there are a lot of other people who agree with him that this is bad enough to be called “a bug”, however intentional it may have been.

But, I also think that this is an overreaction to this particular problem. The solution is simple, and it is what everyone I know dealing with introductory users is telling people:

  1. Never, under any circumstances, use loops etc. in the REPL or in a script, unless wrapped in a function. Period.
  2. If you want to do interactive work, for now you should generally use Jupyter which fixed this “bug” (of course, not really a bug in that it was intentional) with something called SoftGlobalScope, leading to the behavior of before.

If you follow this rule, you will never hit this problem. If I was to guess, the reason we don’t run into this more often is because (1) those teaching beginners always tell people to stick in jupyter, and (2) anyone who is not a beginner is already organizing code in functions.

@StefanKarpinski are there any updates on the timing of the https://discourse.julialang.org/t/another-possible-solution-to-the-global-scope-debacle/ solution?

1 Like

The problem you are facing now has nothing to do with the new scope behaviour.
As others pointed out, you must have defined previously the variable g, then probably forgot about that, and because g is a variable name you cannot create a function with the same name.
It doesn’t work in v0.6 either:

julia> g = "Hi"
"Hi"

julia> function g()
       println("Hello")
       end
ERROR: cannot define function g; it already has a value

julia> versioninfo()
Julia Version 0.6.4
Commit 9d11f62bcb (2018-07-09 19:09 UTC)
Platform Info:
  OS: macOS (x86_64-apple-darwin14.5.0)
  CPU: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell MAX_THREADS=16)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.9.1 (ORCJIT, broadwell)

4 Likes

Yeah, that’s why I asked what value g already had.

1 Like

I think the immediate issue is unrelated (or very weakly related) to scoping — it is simply a pre-existing variable g. Eg

julia> g = 1
1

julia> g() = 1
ERROR: cannot define function g; it already has a value
Stacktrace:
 [1] top-level scope at REPL[2]:1
1 Like

Maybe the error message could be improved… something like: "cannot define function g: "g" is already used as a variable name.

2 Likes

PRs welcome if someone has a better wording, although the current wording seems fairly clear already.

One could read the “it” in the message as “function g”. Then the error will read “function g already has a value” and one might understand from that that you cannot redefine “function g”.
I’d make a PR if I someone could point me in which file the error message is written.

1 Like

I think the issue here is that the error message and the subsequent suggestions/questions on this forum were just completely ignored.

1 Like

Let’s make the most of it and see if we can’t get a better error message out of the experience.

4 Likes

Yup. To me this is an example of noise being generated by the confusion around scoping, which leads people to miss a more obvious problem. I think the error message is otherwise clear if people stop worrying about scope issues, like they were able to before.

1 Like

Yes. That’s exactly right. My subjective global perception concerning Julia suddenly changed on the account of this scoping " tweak." In my mind, it is now a product by programmers for programmers. Within that revised mental model concerning the product, Stefan is correct in stating that my reaction to the scoping rule is an over-reaction.

There was a time in history when one had to be either mechanically inclined, rich and probably both to operate an automobile. My time and cognitive bandwidth are sufficiently limited that it does not make sense for me to operate Julia. Especially, because I imagine that there will probably be more unduly taxing surprises down the road.

Don’t give up. It seems that there is just a simple small missunderstanding which bothers you. If you try to overcome it now you will be rewarded with the best programming environment currently available (my opinion).
I would be more specific but it is not so clear to me what exactly is the problem.

1 Like

He summarized his issue elegantly. While I think that it is largely inaccurate, I have to admit that the scoping issues and the inability to solidify a solution are not a good signal. In my mind, another bad signal is that whenever anyone mentions debuggers on these forums they get attacked with “debuggers are not necessary if you write code properly… i have written 100,000 lines of code without them!” responses.

Luckily, the broader signal we have on both of these is: (1) the scoping issue will be resolved, but they want to make sure they do it right; and (2) lots of people want a Matlab-style debugger, but the funding isn’t there yet and it isn’t something the “power users” have incentives to do on their own.

So, with all of that. I also implore you not to give you, as there are other signals you may have missed.

2 Likes

I would say that this is a misrepresentation, especially in light of recent developments like

Also, while I recognize that you want a debugger, I don’t think that turning this thread into yet another debugger discussion is a good idea.

1 Like

I think it is

1 Like