# Scope behaviors in Atom (Juno)

**URL:** <https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706>\
**Category:** General Usage\
**Created:** [September 16, 2020, 11:33am UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706 "2020-09-16T11:33:30Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![goodluck](https://avatars.discourse-cdn.com/v4/letter/g/65b543/32.png) [@goodluck](https://discourse.julialang.org/u/goodluck)\
**Post date:** [September 16, 2020, 11:33am UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/1 "2020-09-16T11:33:30Z")

</div>

## in [Scope of Variables · The Julia Language](https://docs.julialang.org/en/v1/manual/variables-and-scoping/) it says

What does this code do? Hint: it’s a trick question. The answer is “it depends.” If this code is entered interactively, it behaves the same way it does in a function body. But if the code appears in a file, it prints an ambiguity warning and throws an undefined variable error. Let’s see it working in the REPL first:

```julia-auto
julia> s = 0 # global
0

julia> for i = 1:10
           t = s + i # new local `t`
           s = t # assign global `s`
       end

julia> s # global
55

....

```

* * *

this is not the result i get in 1.5.1:

┌ Warning: Assignment to `t` in soft scope is ambiguous because a global variable by the same name exists: `t` will be treated as a new local. Disambiguate by using `local t` to suppress this warning or `global t` to assign to the existing global variable.  
└ @ none:2  
┌ Warning: Assignment to `s` in soft scope is ambiguous because a global variable by the same name exists: `s` will be treated as a new local. Disambiguate by using `local s` to suppress this warning or `global s` to assign to the existing global variable.  
└ @ none:3  
ERROR: UndefVarError: s not defined  
Stacktrace:  
[1] top-level scope at ./none:2

---

<div class="post-metadata">

**Author:** ![goodluck](https://avatars.discourse-cdn.com/v4/letter/g/65b543/32.png) [@goodluck](https://discourse.julialang.org/u/goodluck)\
**Post date:** [September 16, 2020, 11:43am UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/2 "2020-09-16T11:43:51Z")

</div>

it can hardly get any simpler than this

```julia
s = 0
for i = 1:10
    s += i
end

```

as it says in the documentation [Scope of Variables · The Julia Language](https://docs.julialang.org/en/v1/manual/variables-and-scoping/)

> Obviously the intention is to modify the existing global variable `s` . What else could it mean?

however, the in REPL 1.5.1 it causes warnings and errors

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [September 16, 2020, 11:48am UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/3 "2020-09-16T11:48:48Z")

</div>

> [@goodluck](#):
>
> however, the in REPL 1.5.1 it causes warnings and errors

Not for me at least:

```julia
  | | |_| | | | (_| | | Version 1.5.1 (2020-08-25)
 _/ |\ __'_|_|_|\__'_| | Official https://julialang.org/ release
|__/ |

julia> s = 0
0

julia> for i = 1:10
           s += i
       end

julia>

```

---

<div class="post-metadata">

**Author:** ![goodluck](https://avatars.discourse-cdn.com/v4/letter/g/65b543/32.png) [@goodluck](https://discourse.julialang.org/u/goodluck)\
**Post date:** [September 16, 2020, 1:12pm UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/4 "2020-09-16T13:12:27Z")

</div>

im on a mac, installed via the official process  
julia\> VERSION  
v"1.5.1"

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [September 16, 2020, 1:32pm UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/5 "2020-09-16T13:32:05Z")

</div>

> [@goodluck](#):
>
> however, the in REPL 1.5.1 it causes warnings and errors

Are you actually pasting the code at the REPL prompt (should have no warnings) or using `include` to run it from a file (should have warnings and errors)?

---

<div class="post-metadata">

**Author:** ![goodluck](https://avatars.discourse-cdn.com/v4/letter/g/65b543/32.png) [@goodluck](https://discourse.julialang.org/u/goodluck)\
**Post date:** [September 16, 2020, 2:02pm UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/6 "2020-09-16T14:02:30Z")

</div>

i am pasting it

---

<div class="post-metadata">

**Author:** ![goodluck](https://avatars.discourse-cdn.com/v4/letter/g/65b543/32.png) [@goodluck](https://discourse.julialang.org/u/goodluck)\
**Post date:** [September 16, 2020, 2:05pm UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/7 "2020-09-16T14:05:54Z")

</div>

just found out,

when running REPL from terminal =\> all ok

when running REPL from juno (atom) =\> offending behaviour

both belonging to the same (presumably) julia installation, 1.5.1

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [September 16, 2020, 2:08pm UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/8 "2020-09-16T14:08:56Z")

</div>

> [@goodluck](#):
>
> when running REPL from juno (atom) =\> offending behaviour

So far, Juno has chosen not to implement this. [soft global scope · Issue #174 · JunoLab/Juno.jl · GitHub](https://github.com/JunoLab/Juno.jl/issues/174)

It was very recently changed in vsCode: [softscope on Julia \>=1.5 by pfitzseb · Pull Request #1665 · julia-vscode/julia-vscode · GitHub](https://github.com/julia-vscode/julia-vscode/pull/1665)

---

<div class="post-metadata">

**Author:** ![goodluck](https://avatars.discourse-cdn.com/v4/letter/g/65b543/32.png) [@goodluck](https://discourse.julialang.org/u/goodluck)\
**Post date:** [September 16, 2020, 2:11pm UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/9 "2020-09-16T14:11:00Z")

</div>

omg, this is highly irregular  
i wish they would consider the impact on adoption of julia, from inconsistencies like that  
many thx for ur answer

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [September 16, 2020, 2:42pm UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/10 "2020-09-16T14:42:27Z")

</div>

[https://github.com/JunoLab/Atom.jl/pull/351](https://github.com/JunoLab/Atom.jl/pull/351)

---

<div class="post-metadata">

**Author:** ![goodluck](https://avatars.discourse-cdn.com/v4/letter/g/65b543/32.png) [@goodluck](https://discourse.julialang.org/u/goodluck)\
**Post date:** [September 16, 2020, 3:04pm UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/11 "2020-09-16T15:04:09Z")

</div>

so now im running the code in vscode, via a script (tst.jl) and as you point out, that _should_ produce an error. and it does (see below).

s = 0 # a global variable by the same name exists: `s` will be treated as a new local (in the loop)  
for i = 1:10  
s += i # Assignment to s in soft scope is ambiguous  
end

i must say that i do not understand this scoping rule, it seems completely counterintuitive to me. if a variable `s` existed prior, the user clearly wants to redefine it; at best the parser could warn about it, if and only when a _prior_ `s` existed of another type:

```
s = "hello"
s = 1 # ok to warn here
for i = 1:10
     s += i # no need to warn here
end 

```

whenever you have a construction like that, what is understood intuitively be 99% of all programmers (beginners and professionals alike) to have a certain expected behaviour and is interpreted just like that by the vast majority of other (scripting) languages, there should exist very good reasons for changing things.

on the other hand, if anything is broken in julia, please dont worry about backwards compatibility, please do break old programs. polish julia to be the gem it deserves to be and very nearly is. old programs can be compiled with old compilers / switches and #! preambles.

[Running] julia “/Users/p/tst.jl”

┌ Warning: Assignment to `s` in soft scope is ambiguous because a global variable by the same name exists: `s` will be treated as a new local. Disambiguate by using `local s` to suppress this warning or `global s` to assign to the existing global variable.

└ @ ~/tst.jl:6

ERROR: LoadError: UndefVarError: s not defined

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [September 16, 2020, 3:14pm UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/12 "2020-09-16T15:14:44Z")

</div>

> [@goodluck](#):
>
> i must say that i do not understand this scoping rule, it seems completely counterintuitive to me.

Love it or hate it, one just has to accept it at this point — it can’t be changed in Julia 1.x for non-interactive code without breaking backwards compatibility, which we won’t do.

Background: when Julia 1.0 was released, many people started complaining about the new scoping rules and there was extensive discussion. See e.g.

- [Global variable scope rules lead to unintuitive behavior at the REPL/notebook · Issue #28789 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/28789) and [RFC: bring back v0.6 scope rules in the REPL by JeffBezanson · Pull Request #33864 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/33864)
- Many, many discussions on discourse, e.g. [REPL and for loops (scope behavior change)](https://discourse.julialang.org/t/repl-and-for-loops-scope-behavior-change/13514) … [Remove the soft scope altogether and make it global](https://discourse.julialang.org/t/remove-the-soft-scope-altogether-and-make-it-global/33333) … [Explain scoping confusion to a programming beginner](https://discourse.julialang.org/t/explain-scoping-confusion-to-a-programming-beginner/43206) …

However, putting aside any discussion of the merits of one rule or another, the scoping rules could not be changed in files/modules after Julia 1.0 was released because of the backward-compatibility guarantee (until Julia 2.0 in the _distant_ future). See also [PSA: Julia is not at that stage of development anymore](https://discourse.julialang.org/t/psa-julia-is-not-at-that-stage-of-development-anymore/44872). As a compromise solution, after much debate, the behavior was changed in the interactive REPL (following an earlier experiment in IJulia) — and other interactive environments (vsCode and hopefully soon Juno) are now following suit — with a warning for code in files (scripts and modules).

At this point, there is no point in arguing about it — there is no argument you could possibly make that has not already been made dozens of times.

---

<div class="post-metadata">

**Author:** ![jlperla](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlperla/32/34332_2.png) [@jlperla](https://discourse.julialang.org/u/jlperla)\
**Post date:** [September 16, 2020, 3:48pm UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/13 "2020-09-16T15:48:24Z")

</div>

> [@goodluck](#):
>
> i must say that i do not understand this scoping rule, it seems completely counterintuitive to me

My suggestion is not to try… it is much more subtle than it appears. Instead,

- stick in jupyter for interactive scripts which have top level for loops
- feel free to transition to vscode for interactive stuff which uses the REPL or inline evaluation (which should now be consistent with jupyter, etc. )
- before you ever run it as a `.jl` file on its own, you will want to have any loops in functions.
  - You would want to do that for performance reasons independent of this scoping rules.
  - The warnings will serve as a convenient way to remind you to make that change.

If you do that, you won’t ever have to think about this for a long time - if ever.

---

<div class="post-metadata">

**Author:** ![jlchan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlchan/32/10958_2.png) [@jlchan](https://discourse.julialang.org/u/jlchan)\
**Post date:** [September 16, 2020, 5:14pm UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/14 "2020-09-16T17:14:15Z")

</div>

I think most of Atom/Juno’s developers are [switching to VSCode](https://devclass.com/2020/07/30/juno-julia-for-vscode-1_0/), so I’m not sure if that inconsistency will be fixed.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [September 16, 2020, 6:33pm UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/15 "2020-09-16T18:33:48Z")

</div>

It was [already fixed today](https://github.com/JunoLab/Atom.jl/pull/351).

---

<div class="post-metadata">

**Author:** ![jlchan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlchan/32/10958_2.png) [@jlchan](https://discourse.julialang.org/u/jlchan)\
**Post date:** [September 16, 2020, 6:34pm UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/16 "2020-09-16T18:34:38Z")

</div>

I stand very much corrected…

---

<div class="post-metadata">

**Author:** ![goodluck](https://avatars.discourse-cdn.com/v4/letter/g/65b543/32.png) [@goodluck](https://discourse.julialang.org/u/goodluck)\
**Post date:** [September 17, 2020, 12:08pm UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/17 "2020-09-17T12:08:35Z")

</div>

@jperla, official documentation [https://docs.julialang.org/en/v1/manual](https://docs.julialang.org/en/v1/manual) is not so good wrt the scoping rules. the prose is not clear. it contains seemingly contradictory info. at one point it says

> This eliminated the notion of soft scope…

but it would seem that soft scope still exists… it would be good for the up-to-date documentation to only describe the present functionality. if needed, a discussion of past functionality and contrasting it with the present, should be placed in a totally separate document and linked-to from the current main documentation.

in general the prose is unnecessarily longwinded, talky, musing, joking (sarcastic?).

but most importantly, in the end, it is far from clear _why_ the current (soft?) scoping rule exists. other than

- a facility (as explained in this forum) for being able to paste-insert code chunk `x` into and inside another code chunk `U` without having `x` contaminate `U`
- not having to bother about forgotten variables further up in a long script (as explained in the documentation)

… other than this, no reason, subtle or not, is offered.

if a subtle but substantial reason _does_ exist, im very interested in knowing about it. maybe it will turn me into a staunch advocate of the rule. i am no rocket scientist but i do have a msc in computer science.

as it stands, the counter-intuitive and (to me) bothersome soft-scope remedy seems to me to be much more problematic than what it “fixes”: if you paste-insert code chunk `x` into code chunk `U`, it should be highly intuitive that `x` _will_ contaminate `U` and that it is in _that_ situation that it is reasonable to expect that a little mechanical effort be expended by the programmer/user, eg. by converting `x` into a function. as to “forgetting” about variables further up in a script, you have the parser to kindly point those cases out to you.

btw, before encountering the scopes chapter, i was actually impressed by the clarity, simplicity, brevity of the documentation. scoping should not be an “advanced” or subtle subject, neither intrinsically (=\> leads to poorly designed code and/or code that is hard to maintain) nor because of a confusing documentation (=\> leads to poorly designed code by those who do not abandon julia entirely). i am now reading the types chapter, and once again, i think this chapter could also be tightened, maybe contain half or 1/3 as much text. the chapter’s introduction seems to me to be more of a treatise on cs principles rather than a hands-on practical guide for non-programmers or beginning programmers. but experienced programmers also do not need that discussion, in that prominent place. if needed, it should be placed in a separate document and linked-to from the main documentation. however, the not-so-straightforward language continues through the whole chapter.

please consider my criticism as constructive. i like julia a lot and i hope for it to take off seriously. for that to happen, every friction should be eliminated as soon as possible. as a closing remark, i do not understand the commitment to backwards compatibility; there are many ways to honour that in practice for previous users and programs, eg. by feature/behaviour-freezing the current version into a new maintenance-line of future versions. only from a resource view point does it make sense not to offer two version-lines (“maintenance” and “new-feature”) but if the cost is a stagnating adoption-rate, is that a rational decision? from a business-model point of view, adoption-rate should be the most important KPI, by far.

personally, i think i can live with the quirk, for now.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [September 17, 2020, 3:05pm UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/18 "2020-09-17T15:05:37Z")

</div>

> [@goodluck](#):
>
> if the cost is a stagnating adoption-rate

Just note that for the purposes of this discussion, there is no evidence of this whatsoever. Julia is used by an ever widening audience, but even if it wasn’t, the causal connection to scoping rules (which are pretty arcane for most people) would need to be demonstrated.

It will be possible to argue about these things constructively at the appropriate time (in preparation for 2.0). There is little reason to invoke the “Julia is doomed unless …” line of arguments in the meantime.

> [@goodluck](#):
>
> far from clear _why_ the current (soft?) scoping rule exists

You can find out the history with a trivial investment into researching the issue, [eg here I collected some starting points](https://discourse.julialang.org/t/explain-scoping-confusion-to-a-programming-beginner/43206/17). Just keep in mind that the issue is really complex, and the design space for scoping rules is full of trade-offs with a lot of use cases to cover, so it was a long process with a _lot_ of discussion. IMO the manual may not be the right place for the _history_ of scoping in Julia — it should just document the language as is.

That said, if you find the manual unclear, please consider making a PR. New users are in the unique position to do this, because they still remember the difficulties they encountered.

---

<div class="post-metadata">

**Author:** ![goodluck](https://avatars.discourse-cdn.com/v4/letter/g/65b543/32.png) [@goodluck](https://discourse.julialang.org/u/goodluck)\
**Post date:** [September 17, 2020, 3:15pm UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/19 "2020-09-17T15:15:27Z")

</div>

ok, thanks for reading and replying and indicating where to dig deeper - i will do that with interest. im afraid i do not have the time nor the qualifications to contribute at this moment beyond my novice considerations, aired here.

btw

> @Tamas_Papp said: IMO the manual may not be the right place for the _history_ of scoping in Julia — it should just document the language as is.

agree 100%

---

<div class="post-metadata">

**Author:** ![goodluck](https://avatars.discourse-cdn.com/v4/letter/g/65b543/32.png) [@goodluck](https://discourse.julialang.org/u/goodluck)\
**Post date:** [September 17, 2020, 8:47pm UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/21 "2020-09-17T20:47:02Z")

</div>

> [@Non-friendly documentation](https://discourse.julialang.org/t/non-friendly-documentation/38109/119):
>
> i finished reading the types section of the julia documentation [Types · The Julia Language](https://docs.julialang.org/en/v1/manual/types). it really, in my opinion, is quite bad. i appreciate that a great effort must have gone into making that chapter and i have really been trying to like it. but it plain simply is not a very attractive disposition; i believe it does not produce the kind of understanding and excitement in the reader that would correspond to the merits of julias type system; a system which really has great practical utility. …

[Next page](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706.md?page=2)