1.0 is the next major version (there'll be an 0.7 to give us an extra deprecation cycle and start 1.0 without any depwarns, but 0.7 will essentially be identical to 1.0 otherwise). You can follow the 1.0-blocking issues here: https://github.com/JuliaLang/julia/milestone/4.
Unrelatedly, have the Julia devs decided to require variable declaration yet? E.g. "local x = 1" instead of just "x = 1"? Or better yet, "x := 1"?
How many times does this mistake have to be repeated in various languages? It'll just be a matter of time before people are banging on for a strict mode, and rightfully so.
Python and Ruby do this without a problem. Many others do it too. If there's a set of complaints about those two languages, variable scope isn't in the top ten.
If you're gonna do lexical scoping or some variation of, defaulting to the current scope makes the most sense. Defaulting to global scope is what causes the issue, not choice of keywords.
Not entirely without a problem. Not being explicit about declaring variables means you need to be explicit about not declaring variables when assigning to a variable in an enclosing scope, i.e. Python's "nonlocal" and "global" keywords. (Which is, if not a problem, at least a little ugly.)
I thought about this. I would just avoid the need of declaring a variable with the same name as one in the enclosing scope. That means minimisation of global variables, minimisation of lexical pyramids, etc. Generally good things with or without explicit declarations.
If you're creating a closure, that's inherent part of the enclosing scope. Just like variable reuse is discouraged for clarity, so it should in closures.
I think declaring a global variable deep in scope sounds like recipe for hell. I think declaring a global with a name as short as you'd use in function parameters is a mistake. I don't see how it'd be a problem if you follow practices that encourage maximum clarity.
If I could see an example, it'd make it easier to understand your point - I haven't seen the problem you describe so it's difficult for me to visualise it.
def f():
def g():
nonlocal x # change this line
x = 3
print("x == {!r}".format(x))
x = 2
g()
print("x == {!r}".format(x))
x = 1
f()
print("x == {!r}".format(x))
It will print (because g reassigns the x in f):
x == 3
x == 3
x == 1
and if you change "nonlocal" to "global", g will reassign the global x, and you get:
x == 3
x == 2
x == 3
and if you remove the line entirely, the assignments will be interpreted as declaring new variables in each scope, and you get :
I just looked up the nonlocal keyword, my python isn't strong. I'll hold my hands up - python wasn't a good example here. I was under the impression you could use and mutate outer scope variable.
Except in language(s) that default to the global scope without declaration. I admit it though - if the compiler doesn't, a static analysis tool will do my point is shaky.
I'm not passionately for implicit declarations. I just don't see it as a make or break, stupid idea that the OP made it out to be.
If I had a choice, I would prefer explicit, with compiler errors when not declared up scope as opposed to implicit declaration in the global scope.
While I do think it is a stupid idea, whether or not it's make or break will of course depend on what else the laguage has to offer and what the alternatives are.
I've used JavaScript and PHP in the past (and even enjoyed it!), never mind all the misfeatures of said languages. What bugs me though is that language designers keep making the same mistakes over and over again...
PHP scoping is what happens when each scope, including parent and child scopes are completely isolated (except 'superglobals', of which globals are within).
To create a closure, you must use "use" and specify the variables to close over. To use globals, you have to say "I want this to be from the global scope or make a global otherwise".
Leads to a lot of verbose code and cripples ability to really use FP ideas.
