# New scope solution
**URL:** https://discourse.julialang.org/t/new-scope-solution/16707
**Category:** Internals & Design
**Tags:** proposal
**Created:** [October 23, 2018, 8:58pm UTC](https://discourse.julialang.org/t/new-scope-solution/16707 "2018-10-23T20:58:16Z")
**Posts on this page:** 16
**Page:** 12
### Author:  [@piever](https://discourse.julialang.org/u/piever)
#### Post date: [January 30, 2019, 12:22am UTC](https://discourse.julialang.org/t/new-scope-solution/16707/225 "2019-01-30T00:22:53Z")
This has been mentioned already I think: somehow it seems like there are two valid notions of `let`. There is a local one that is used only to get an output (which is I think how `let` is originally intended to be used in functional programming languages):
```julia
let a = 1
x = a + 1
x - 3
end
```
and then there could be a global one that is used to define global variables that depend on local ones:
```julia
let a = 1
global g(x) = x + a
global y = a + 12
end
```
I imagine this could be changed so that the former would be written as:
```julia
local let a = 1
x = a + 1
x - 3
end
```
and the latter as:
```julia
let a = 1
g(x) = x + a
y = a + 12
end
```
Similarly, the default `for` loop would become “global” and for the local version one would write `local for` (this is pedagogically less of a concern as both `local let` and `local for` would not be used by beginners).
Then the rule would be: variables are global unless inside a function or in a block labelled with `local`. A (local) `for` loop is like a repeated (local) `let`.
I don’t necessarily think this is the best way forward (after an initial strong aversive reaction, I’m starting to see the merit of Julia 1.0 scoping rules), but I wanted to point out this possibility.
---
### Author:  [@jballanc](https://discourse.julialang.org/u/jballanc)
#### Post date: [January 30, 2019, 1:38am UTC](https://discourse.julialang.org/t/new-scope-solution/16707/226 "2019-01-30T01:38:02Z")
> [@braamvandyk](#):
>
> Basically I would really like for the core devs to make a call on whatever criteria they believe are the most important and then that is that. Everyone else will get used to things and move on with their lives.
I agree with your desire, but I think there’s a bit more to it on the community side than just “accept and move on”. As the discussions around this issue are old and beginning to repeat themselves with increasing frequency, I would expect the way forward from here to look something like:
1. core team evaluates, internally, **ALL** criteria w.r.t. ease of use, community adoption, performance, simplicity, etc., etc. and decide on a solution
2. the solution appears as a PR and set of criteria (indeed, this has already happened)
3. if the core team is not happy with the implementation `GOTO 1`, else continue
4. completed solution is scheduled for inclusion in a future Julia release
5. solution appears in the wild and we all start this debate anew (or move on to the next one)
I agree with @braamvandyk that, at this point, it’s probably best for #1 to be left to the core team (and I, for my part, will refrain from any further “armchair PL design” going forward). I do look forward to helping out with #2, though, but I do think there is a fine line between dispassionately helping vet and validate the implementation of a solution and pushing the solution in a certain preferred direction. As for #3, I feel again this is the core team’s prerogative, and feedback is probably best left to requests for such from them.
Step #4 has me most concerned. In a perfect world, the core team designs the perfect solution and designates it for release in accordance with SemVer principles. In the real world, there’s obviously going to be a balance between how much we are willing to bend SemVer in the service of potentially having a better solution and not having to wait for (or prematurely declare) Julia v2.0. I expect the community will have a role to play in advocating for and assisting with any small SemVer violations that might be necessary. (e.g.: SemVer violations bite most when they cause packages to break unexpectedly. If, say, a solution were scheduled for release in v1.3 and the community worked overtime to discover breakages in public packages ahead of time, I imagine things will go more smoothly.)
As for Step #5, I wonder: has anyone given thought to a Julia community survey? It seems this is the season for language/developer community surveys (I’ve completed 5 just this week), and Julia is somewhat of a conspicuous absence. Much of the hemming and hawing in this and other threads have been around what “teachers” or “students” prefer…but without data, it’s all speculation and hearsay.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [January 30, 2019, 8:27am UTC](https://discourse.julialang.org/t/new-scope-solution/16707/227 "2019-01-30T08:27:30Z")
> [@stevengj](#):
>
> Was there any case in which the 0.6 semantics were honestly a real obstacle for you? Or is it just philosophically distasteful?
I ran into the soft/hard distinctions quite a bit. Not all the time, in fact rarely enough that I usually would not suspect them as the source of the problem so it would take some time to track down the resulting bugs. Which is why I was very relieved with the new scoping rules, I find them elegant and I also like the fact that _I get errors instead of the language trying to figure out what I meant._
> [@stevengj](#):
>
> The global scope semantics are mostly irrelevant to complex packages
I would argue with this, eg
> [@Another possible solution to the global scope debacle](https://discourse.julialang.org/t/another-possible-solution-to-the-global-scope-debacle/15894/152):
>
> Late to the party here. making everything outside of a function global, unless it is explicitly declared with local or let Would variables inside the body of a let block be global? (Presumably, yes, see [here](https://discourse.julialang.org/t/another-possible-solution-to-the-global-scope-debacle/15894/106).) If so, then IIUC this would nix being able to reliably copy/paste the body of a function into a let block (a common debugging strategy, whether performed manually or via Rebugger). For example, if I did this for a function which had a line first = true (defining a local variable named f…
Changing scoping can have a lot of unforeseen consequences (especially in corner cases) in a complex language. So in a sense, my objection to introducing _ad hoc_ rules is indeed philosophical: I am concerned that issues will surface later on, and for me the benefits just do not justify the risk of this (but of course, I am recognizing that other people have different preferences; I am just stating my own).
---
### Author:  [@ninjaaron](https://discourse.julialang.org/u/ninjaaron)
#### Post date: [January 30, 2019, 10:56am UTC](https://discourse.julialang.org/t/new-scope-solution/16707/228 "2019-01-30T10:56:08Z")
> [@StefanKarpinski](#):
>
> I want to underline this. There are a lot of people here talking about this as if the ≤ 0.6 behavior was perfect and everyone wishes that we could go back to it. […]
Thanks so much for taking the time to provide this great explanation.
After considering what you said, I still prefer the 1.0 solution, but I think you make a convincing case that the patch behavior is better than the 0.6 behavior. It’s a little too “subtle” for my taste, in terms of readability, but I definitely get what you’re saying about the benefit of being statically resolvable.
---
### Author:  [@BioTurboNick](https://discourse.julialang.org/u/BioTurboNick)
#### Post date: [January 31, 2019, 4:32pm UTC](https://discourse.julialang.org/t/new-scope-solution/16707/229 "2019-01-31T16:32:32Z")
I haven’t been able to read most of this, though I’ve been through the more recent bits-- is there an opportunity to, at the REPL, “make it work” but just emit a warning when it does? Perhaps based on a flag that a REPL could use but which would be off for normal execution? (Thinking out loud naively here.)
In most of these cases being talked about, the warning would disappear when the user moved the code into a function. And the warning would make sure the user knew that if they wanted to really work with a global variable in normally executing code they’d have to specify the scope, where the warning would become an error.
---
### Author:  [@heliosdrm](https://discourse.julialang.org/u/heliosdrm)
#### Post date: [February 7, 2019, 10:52am UTC](https://discourse.julialang.org/t/new-scope-solution/16707/230 "2019-02-07T10:52:30Z")
**TL;DR** : Does this PR affect to all constructs that introduce a local scope, including functions?
Sorry to resurrect the thread; it is not my intention to raise a new loop of repeated arguments, but to solve the specific question written above.
Motiviation of the quesion: most of the time the discussion has gone around the behavior of `for` loops (and comprehensions) at top level, because that is the situation where the current behavior is problematic in some circumstances (e.g. some teaching practices). The tests included in the PR ([WIP,RFC: flow-based scope in top-level expressions by JeffBezanson · Pull Request #30843 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/30843)) are also limited to `for` loops. But is this also affecting the scoping rules of other other local constructs?
My question is specially about functions, like this:
```julia
grow(x) = (a+=1)*x
```
In Julia 1.0, 1.1 this works only if `grow` is in a local scope that is also the scope of `a`, e.g. if both `a` and `grow` are defined inside another function. (For instance, `grow` might be an inner function used to calculate a geometric progression with a variable rate `a`.)
On the other hand, if `grow` is defined at top level, currently it fails. This looks like a sane behavior, since at top level you don’t have the control on the variable value of `a` that you would have in a function.
So, my question is: does the PR also change this behavior, such that `grow` would “work” at top level too? I have tried to look at the code of the PR, but it is beyond my understanding, sorry.
---
### Author:  [@mauro3](https://discourse.julialang.org/u/mauro3)
#### Post date: [February 7, 2019, 1:56pm UTC](https://discourse.julialang.org/t/new-scope-solution/16707/231 "2019-02-07T13:56:51Z")
This still works the same.
---
### Author:  [@heliosdrm](https://discourse.julialang.org/u/heliosdrm)
#### Post date: [February 7, 2019, 9:46pm UTC](https://discourse.julialang.org/t/new-scope-solution/16707/232 "2019-02-07T21:46:09Z")
Sorry, I don’t fully understand what this means. Does it mean that the PR does modify the rules of all local scopes (`for`, `while` loops, `let` blocks, functions, etc. - see the list in [Scope of Variables · The Julia Language](https://docs.julialang.org/en/v1/manual/variables-and-scoping/))?
---
### Author:  [@ninjaaron](https://discourse.julialang.org/u/ninjaaron)
#### Post date: [February 9, 2019, 10:37am UTC](https://discourse.julialang.org/t/new-scope-solution/16707/233 "2019-02-09T10:37:40Z")
The PR does not modify anything about the behavior in a local scope. It’s just special sauce for the global scope.
---
### Author:  [@heliosdrm](https://discourse.julialang.org/u/heliosdrm)
#### Post date: [February 9, 2019, 10:57pm UTC](https://discourse.julialang.org/t/new-scope-solution/16707/234 "2019-02-09T22:57:17Z")
Thanks for the reply and your patience. But I have the feeling that I was not clear in the way I presented the question. Ok: nothing related to local variable changes, but variables from the parent global scope would be inherited for writing into local scope constructs, in some circumstances. This I already understood.
I’ll put my question again more briefly. Is this a special rule in `for` loops as would look from the examples that have been discussed, or does it apply to any construct that introduces a local scope, including functions? Would this function work if the function is defined in top-level (and `a` is defined in the parent global scope)?
```julia
grow(x) = (a+=1)*x
```
Thanks again, and please bear with my dumbness if this was already clear from the previous discussion.
---
### Author:  [@gdkrmr](https://discourse.julialang.org/u/gdkrmr)
#### Post date: [February 10, 2019, 8:44am UTC](https://discourse.julialang.org/t/new-scope-solution/16707/235 "2019-02-10T08:44:12Z")
the two global scope threads are the longest on discourse 🙂
---
### Author:  [@ceysa75](https://discourse.julialang.org/u/ceysa75)
#### Post date: [January 13, 2020, 4:01pm UTC](https://discourse.julialang.org/t/new-scope-solution/16707/236 "2020-01-13T16:01:26Z")
Dear All,
I am working in a company where we use matlab as a tool for rather simple tasks than complicated programs. I am really struggling to replace Matlab with Julia, I am on a good way, though. But this scoping thing (and the time to first plot issue) are the main obstacles which prevents me to reach my goal. I mean from my colleagues perspective there is no serious reason to switch. However, they are willing to. But the two points as adressed above make them feel uncomfortable. I really really would like to see that Stefan’s proposal (first post) would be implemented in the near future. However, I have the impression that the Julia community has stopped thinking about that. Am I right by saying that?
Best regards
CS
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [January 13, 2020, 4:16pm UTC](https://discourse.julialang.org/t/new-scope-solution/16707/237 "2020-01-13T16:16:05Z")
> [@ceysa75](#):
>
> I have the impression that the Julia community has stopped thinking about that. Am I right by saying that?
No. See recent activity:
>
>
> After thinking about it off and on for quite a while, @StefanKarpinski and I mor…e-or-less decided that the best way to change the REPL scope situation (if at all) is just to bring back what v0.6 did. That's what SoftGlobalScope and IJulia already do (albeit somewhat approximately; implementing it internally it's much easier to get it 100%), and seems less disruptive than introducing a \*third\* behavior.
>
> This needs to be finished up but is ready to try. Please give it a whirl.
>
> I'm not sure what the best interface to it is; it seemed easiest just to drop a special expression in the AST itself.
>
> fixes #28789
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [January 13, 2020, 10:19pm UTC](https://discourse.julialang.org/t/new-scope-solution/16707/238 "2020-01-13T22:19:47Z")
> [@ceysa75](#):
>
> But the two points as adressed above make them feel uncomfortable
They can just use Jupyter for interactive work, since IJulia uses soft scoping.
---
### Author:  [@ceysa75](https://discourse.julialang.org/u/ceysa75)
#### Post date: [January 14, 2020, 4:18pm UTC](https://discourse.julialang.org/t/new-scope-solution/16707/239 "2020-01-14T16:18:34Z")
Thank you for the information. Have read now a lot in that huge thread. However, unfortunately it seems that the community is far from being in agreement in this regard. I am not able to follow and understand everything. In my (simple) world the scope issue shouldn’t be an issue at all…
---
### Author:  [@jlperla](https://discourse.julialang.org/u/jlperla)
#### Post date: [January 14, 2020, 5:47pm UTC](https://discourse.julialang.org/t/new-scope-solution/16707/240 "2020-01-14T17:47:28Z")
> [@ceysa75](#):
>
> I am not able to follow and understand everything. In my (simple) world the scope issue shouldn’t be an issue at all…
It is very difficult for people coming from Matlab, since when you write a script in matlab things are only global if you mark them as such.
I think that the advice to use Jupyter notebooks is the best one, as people will find the scoping rules there completely intuitive. By the time they are ready to move to Atom/etc. they will have trained their brains enough to deal with the issue.
[Previous page](https://discourse.julialang.org/t/new-scope-solution/16707.md?page=11)