# Feature request and Brainstorming , global let (issue #37187)
**URL:** https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837
**Category:** Internals & Design
**Created:** [October 6, 2020, 6:48am UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837 "2020-10-06T06:48:45Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@systems](https://discourse.julialang.org/u/systems)
#### Post date: [October 6, 2020, 6:48am UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/1 "2020-10-06T06:48:45Z")
This is a feature request proposal Brain Storming
**The proposal (initially)**
1. add construct `global let` to julia
```julia
global let
...
end
```
1. Scripts (without) module declaration should assume being inside a` global let`
2. add `our` and `my` as synonym to `global` and `local`
Inside a global let all variables and functions are global by default,
unless explicitly declared `local`
**What does this fix and how does it help**
1. allow local variables in a file (file scope)
2. make it easier to use the repl
3. bridge or eliminate the gap between file scope and repl scope
4. promote variable declaration before use (variable autovivification considered harmful)
I will explain below how this is this case
**first some quirks**
Currently this code below generate an error inside a file raise an error and a warning
```julia
s = 0
for i = 1:10
t = s + i
s = t
println("$s")
end
println("$s")
┌ Warning: Assignment to `s` in soft scope is ...
ERROR: LoadError: UndefVarError: s not defined
```
this code still raise an error
```julia
local s = 0
for i = 1:10
t = s + i
s = t
println("$s")
end
println("$s")
ERROR: LoadError: UndefVarError: s not defined
```
and this code still an error
```julia
global s = 0
for i = 1:10
t = s + i
s = t
println("$s")
end
println("$s")
┌ Warning: Assignment to `s` in soft scope is ...
ERROR: LoadError: UndefVarError: s not defined
```
Now put the code inside a let, and the problem is solved
```julia
let
global s = 0
for i = 1:10
t = s + i
s = t
println("$s")
end
println("$s")
end
```
And `s` is global and available for me outside the `let` all 3 variations will work, the difference is the visibility of `s` outside the let
I understand that the Julia way to fix this was to add global or local next to the first use of s inside the loop
and if I want s to be local that would not be so bad, but for a `global s` this is very counter intuitive
**Mimicking file scope**
Example
```julia
# file one.jl
let
global x =1
local y = 2
local function addx( a )
println( x + a)
end
global function addy( a )
println(y + a)
end
addy(3)
addx(3)
end
#file two.jl
include("one.jl")
println(x)
addy(10)
#println(y) #raise error
#addx(10) #raise error
```
If we have global let file one.jl would look like
```julia
# file one.jl
global let
x =1
local y = 2
local function addx( a )
println( x + a)
end
function addy( a )
println(y + a)
end
addy(3)
addx(3)
end
```
And would work just the same
Also if `global let` becomes implicit, file one.jl could look like this and still work just the same, allowing local variables that are file scoped
```julia
# file one.jl
x =1
local y = 2
local function addx( a )
println( x + a)
end
function addy( a )
println(y + a)
end
addy(3)
addx(3)
```
**The case for `my` and `our`**
my and our are much shorter than global and local,will make the code look nicer and might motivate more developers to declare that variable scope before use
```julia
# file one.jl
x =1
my y = 2
my function addx( a )
println( x + a)
end
function addy( a )
println(y + a)
end
addy(3)
addx(3)
```
or
```julia
# file one.jl
our let
x =1
my y = 2
my function addx( a )
println( x + a)
end
function addy( a )
println(y + a)
end
addy(3)
addx(3)
end
```
**Show stoppers**
`module` must be declared at the top level and cannot be declared inside a let , I am not sure what the impact of allowing `module` declaration inside `let`s would be, and this is a big problem
But if making global lets implicit is impossible for some reason I could not preview, I still think that having the syntax variation of `global let` , `my` and `our` is still worth it
```julia
our let
my y = 1
addy(a)
a + y
end
...
end
vs
let
y = 1
global addy(a)
a + y
end
...
end
```
Anyway, hope to get some feedback, do you think global lets is a good idea, does it have a chance?
---
### Author:  [@systems](https://discourse.julialang.org/u/systems)
#### Post date: [October 6, 2020, 2:10pm UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/2 "2020-10-06T14:10:07Z")
I thought a bit more about this, and I think I found a fix for what I thought was the show stopper
modules simply should behave the same as `global let` , this will unify all scoping rules
- inside modules
- inside files, without a module declaration (again files will assume a global let)
- inside the REPL
To summarise my request
1. add `global let` where inside the let variables and functions are global by default unless explicitly declare `local`
2. add `our` and `my` as synonym to `global` and `local`
3. modules, files and the REPL will assume to wrap all its content inside a `global let` (this will allow to declare private/`local` module variables, file scoped variables and unify the scoping rules between all 3)
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [October 6, 2020, 2:46pm UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/3 "2020-10-06T14:46:50Z")
I’m a bit unclear about these motivations:
> 1. allow local variables in a file (file scope)
Ok, but why? What’s the benefit of this? Presumably when you say “local variables in a file” you mean a variable that behaves as if you had wrapped the file in a let block and declared the variable in the let block. So it would be accessible from any functions within that let block but would not be accessible from outside the let block.
> 1. make it easier to use the repl
How does this make it easier to use the REPL? What concrete problem in the REPL does this solve?
> 1. bridge or eliminate the gap between file scope and repl scope
In what way? Again, what concrete problem does this address? What is the gap between file scope and REPL scope that this is eliminating?
> 1. promote variable declaration before use (variable autovivification considered harmful)
Julia doesn’t do any autovivification. If you assign to a variable in global scope, that creates or updates a global. Unlike e.g. Perl (presumably where you’re coming from since you propose `my` and `our` as modifiers), accessing a global that doesn’t exist does not “autovivify” it—it’s an undefined variable error. If you want to assign to a global from a local scope, you need to declare it as `global`.
---
### Author:  [@systems](https://discourse.julialang.org/u/systems)
#### Post date: [October 6, 2020, 3:27pm UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/4 "2020-10-06T15:27:49Z")
Before I explain myself, I want to make it clear, I think this change is mostly aesthetic and syntactic
it doesn’t really add any new features to Julia
It just makes using some features easier
You can today, wrap all the code inside your module inside a let have have local module variable
Also today you can wrap all the code inside you file inside a let and have local file variables that will not be accessible to other scripts that include your file
So this is mostly syntactic and convenience
> [@StefanKarpinski](#):
>
> I’m a bit unclear about these motivations:
>
> > 1. allow local variables in a file (file scope)
>
> Ok, but why? What’s the benefit of this? Presumably when you say “local variables in a file” you mean a variable that behaves as if you had wrapped the file in a let block and declared the variable in the let block. So it would be accessible from any functions within that let block but would not be accessible from outside the let block.
Yes exactly, and I understand its not a big thing, just convenience, and check the below
```julia
# example 1
global s = 0
for i = 1:10
t = s + i
s = t
println("$s")
end
println("$s")
# example 2
s = 0
for i = 1:10
t = s + i
global s = t
println("$s")
end
println("$s")
```
To me, example 1, look more natural, yet today it will raise an error unless wrapped inside a let
if global let becomes the default behavior for file (and modules) example 1 will just work, and I think this is a good thing
> [@](#):
>
> > 1. make it easier to use the repl
>
> How does this make it easier to use the REPL? What concrete problem in the REPL does this solve?
>
> > 1. bridge or eliminate the gap between file scope and repl scope
>
> In what way? Again, what concrete problem does this address? What is the gap between file scope and REPL scope that this is eliminating?
If `global let` become the default behavior for files, modules and REPL, you wont need different scoping rules for the REPL and file, I think this is a good thing, less cognitive burden
I can still simulate this today, if I wrap all my code inside `let`s and carefully label all my functions and variables `local` or `global`, it is just a convenience I doubt it will break any code
> [@](#):
>
> > 1. promote variable declaration before use (variable autovivification considered harmful)
>
> Julia doesn’t do any autovivification. If you assign to a variable in global scope, that creates or updates a global. Unlike e.g. Perl (presumably where you’re coming from since you propose `my` and `our` as modifiers), accessing a global that doesn’t exist does not “autovivify” it—it’s an undefined variable error. If you want to assign to a global from a local scope, you need to declare it as `global`.
I agree with you, I misused the word autovivification, my bad
And thanks for taking the time to check this 🙂 really appreciate it
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [October 7, 2020, 8:16am UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/5 "2020-10-07T08:16:12Z")
> [@systems](#):
>
> example 1, look more natural,
This is in the eye of the beholder; also in 1.5 you don’t need the `global` at all, just use
```julia
s = 0
for i = 1:10
t = s + i
s = t
println("$s")
end
```
---
### Author:  [@systems](https://discourse.julialang.org/u/systems)
#### Post date: [October 7, 2020, 12:41pm UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/6 "2020-10-07T12:41:58Z")
> [@Tamas\_Papp](#):
>
> This is in the eye of the beholder; also in 1.5 you don’t need the `global` at all, just use
>
> ```julia
> s = 0
> for i = 1:10
> t = s + i
> s = t
> println("$s")
> end
>
> ```
I am running 1.5.2 and I get an this error
```julia
PS C:\dev\lang\julia> julia --version
julia version 1.5.2
PS C:\dev\lang\julia> julia .\testscope.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.
└ @ C:\dev\lang\julia\testscope.jl:4
ERROR: LoadError: UndefVarError: s not defined
Stacktrace:
[1] top-level scope at C:\dev\lang\julia\testscope.jl:3
[2] include(::Function, ::Module, ::String) at .\Base.jl:380
[3] include(::Module, ::String) at .\Base.jl:368
[4] exec_options(::Base.JLOptions) at .\client.jl:296
[5] _start() at .\client.jl:506
in expression starting at C:\dev\lang\julia\testscope.jl:2
```
And actually if my feature got accepted this code will run as if it was
```julia
let
global s = 0
for i = 1:10
t = s + i
s = t
println("$s")
end
end
```
but you will either write it
```julia
global let
s = 0
# s becomes global by default, and will be available out side the let
# to make it local you would need to explicitly
# specify this by using the local keyword, or hopefully the shorter my keyword
for i = 1:10
t = s + i
s = t
println("$s")
end
end
```
or just (if global let becomes default or implicit inside files and modules)
```julia
s = 0
for i = 1:10
t = s + i
s = t
println("$s")
end
```
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [October 7, 2020, 12:46pm UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/7 "2020-10-07T12:46:19Z")
> [@systems](#):
>
> I am running 1.5.2 and I get an this error
I am confused now, originally your proposed this feature to
> [@systems](#):
>
> make it easier to use the repl
but now you are testing it in non-interactive mode. Are you aware that the two have different scoping behavior? See
[https://docs.julialang.org/en/v1/manual/variables-and-scoping/#Local-Scope](https://docs.julialang.org/en/v1/manual/variables-and-scoping/#Local-Scope)
---
### Author:  [@systems](https://discourse.julialang.org/u/systems)
#### Post date: [October 7, 2020, 12:49pm UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/8 "2020-10-07T12:49:29Z")
> [@Tamas\_Papp](#):
>
> but now you are testing it in non-interactive mode. Are you aware that the two have different scoping behavior? See
>
> [Scope of Variables · The Julia Language](https://docs.julialang.org/en/v1/manual/variables-and-scoping/#Local-Scope)
Yes, exactly.
A `global let` will unify the rules
If a file have a global let behavior by default, and the repl have a global let behavior by default, we wont need different scoping rules, hence making using the repl, in my opinion easier
---
### Author:  [@systems](https://discourse.julialang.org/u/systems)
#### Post date: [October 7, 2020, 12:54pm UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/9 "2020-10-07T12:54:02Z")
To clarify
I am suggesting
1. an explicit `global let` , which is allowing the use of the key word global with a let block to reverse the scoping of variables, from local by default to global by default
2. an implicit` global let` inside file, modules and the repl (to unify the scoping rules and allow local variables inside files and modules)
Since you cannot define a module inside a `let` block , the two will be a bit different
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [October 7, 2020, 1:14pm UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/10 "2020-10-07T13:14:46Z")
Sorry, I still don’t understand what problem this addresses. Also, given that
> [@systems](#):
>
> Since you cannot define a module inside a `let` block , the two will be a bit different
I am not sure I understand the aesthetic argument either.
---
### Author:  [@systems](https://discourse.julialang.org/u/systems)
#### Post date: [October 7, 2020, 1:35pm UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/11 "2020-10-07T13:35:54Z")
> [@Tamas\_Papp](#):
>
> I am not sure I understand the aesthetic argument either.
Aesthetic are completely subjective
And I think it is a nice to have feature, that I believe will not cause any trouble
I think that this code , and being explicit about what is private
(and I think using shorter keyword helps even more)
```julia
our let
x = 1
my y = 2
my function addx( a )
println( x + a)
end
function addy( a )
println(y + a)
end
end
```
Looks better, than , where you are explicit about globals
```julia
let
global x = 1
y = 2
function addx( a )
println( x + a)
end
global function addy( a )
println(y + a)
end
end
```
I fully understand, that not all will agree, and while functions want to be global by default, variables want to be local by default, so I think if we have both options (both types of let block) will satisfy all tastes
The side benefit of the top example, is that if it becomes the default behavior inside modules and file, it will also unify scoping rules with the repl
**Also another interesting side effect, is you will get local variables in modules and files**
---
### Author:  [@pdeffebach](https://discourse.julialang.org/u/pdeffebach)
#### Post date: [October 7, 2020, 1:48pm UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/12 "2020-10-07T13:48:22Z")
you can use the `@softscope` macro from SoftScope.jl for this as well.
```julia
s = 0
@softscope for i in 1:10
s += i
end
```
---
### Author:  [@Sukera](https://discourse.julialang.org/u/Sukera)
#### Post date: [October 7, 2020, 2:26pm UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/13 "2020-10-07T14:26:38Z")
I feel like you aren’t aware of the much too long history these kinds of discussions have already had…
Just a few links (most recent to least recent):
- [Return of the soft scope blog post](https://julialang.org/blog/2020/08/julia-1.5-highlights/#the_return_of_soft_scope_in_the_repl) - most recent changes new in 1.5
- [New scope solution](https://discourse.julialang.org/t/new-scope-solution/16707), in which the changes from above where discussed extensively (includes _too many links_ to previous discussions to count them all)
- [Another possible solution to the global scope debacle](https://discourse.julialang.org/t/another-possible-solution-to-the-global-scope-debacle/15894), the discussion preceding the discussion from above (again, _too many links and posts to summarize_)
- [Infamous Issue #28789](https://github.com/JuliaLang/julia/issues/28789), which was the source of the most recent set of changes
- …and a bunch more from before the 1.0 days which are either too outdated to be useful or I can’t find them anymore.
Please be aware that these changes have had just so many hours poured in that frankly, it feels a bit imposing bringing it up again so shortly after the initial release of 1.5.
Also, [Julia is (hopefully, finally) not at that stage of development anymore](https://discourse.julialang.org/t/psa-julia-is-not-at-that-stage-of-development-anymore/44872).
---
### Author:  [@Sukera](https://discourse.julialang.org/u/Sukera)
#### Post date: [October 7, 2020, 2:32pm UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/15 "2020-10-07T14:32:26Z")
> [@lmiq](#):
>
> Actually from the docs one would think that a warning would be printed, but not an error:
The warning prints either way, the error is only thrown when the code actually runs:
```Bash
Projects $ cat test.jl
i = 0
if rand() < 0.5
for x in 1:10
i += x
end
end
println(i)
Projects $ julia test.jl
┌ Warning: Assignment to `i` in soft scope is ambiguous because a global variable by the same name exists: `i` will be treated as a new local. Disambiguate by using `local i` to suppress this warning or `global i` to assign to the existing global variable.
└ @ /d/Documents/Projects/test.jl:4
0
Projects $ julia test.jl
┌ Warning: Assignment to `i` in soft scope is ambiguous because a global variable by the same name exists: `i` will be treated as a new local. Disambiguate by using `local i` to suppress this warning or `global i` to assign to the existing global variable.
└ @ /d/Documents/Projects/test.jl:4
ERROR: LoadError: UndefVarError: i not defined
Stacktrace:
[1] top-level scope at /d/Documents/Projects/test.jl:4
[2] include(::Function, ::Module, ::String) at ./Base.jl:380
[3] include(::Module, ::String) at ./Base.jl:368
[4] exec_options(::Base.JLOptions) at ./client.jl:296
[5] _start() at ./client.jl:506
in expression starting at /d/Documents/Projects/test.jl:2
```
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [October 7, 2020, 2:36pm UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/16 "2020-10-07T14:36:37Z")
What is the difference between the two executions there? I could not get that.
---
### Author:  [@Sukera](https://discourse.julialang.org/u/Sukera)
#### Post date: [October 7, 2020, 2:39pm UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/17 "2020-10-07T14:39:47Z")
At runtime, a random value is chosen (`rand() < 0.5`) and depending on that the `for` loop executes or not. The point is that it doesn’t matter whether the loop runs or not - there is a warning that’s printed:
```julia
┌ Warning: Assignment to `i` in soft scope is ambiguous because a global variable by the same name exists: `i` will be treated as a new local. Disambiguate by using `local i` to suppress this warning or `global i` to assign to the existing global variable.
└ @ /d/Documents/Projects/test.jl:4
```
You probably just missed it, because Discourse doesn’t have fancy syntax highlighting, but in a terminal (or at least my terminal) the warning is clearly visible because of its yellow color:
The `Error` is only thrown in the branch where the code actually tries to read from a non-existent `i` in the for loop.
---
### Author:  [@systems](https://discourse.julialang.org/u/systems)
#### Post date: [October 7, 2020, 3:42pm UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/19 "2020-10-07T15:42:06Z")
> [@Sukera](#):
>
> I feel like you aren’t aware of the much too long history these kinds of discussions have already had…
>
> …
>
> Also, [Julia is (hopefully, finally) not at that stage of development anymore](https://discourse.julialang.org/t/psa-julia-is-not-at-that-stage-of-development-anymore/44872).
I completely agree with you
But I still think that having the **explicit** `global let` and adding `our` and `my` a shorter alternatives for `global` ad `local` are nice features to add, for some people it will make their code more natural and simpler to read
Having an **implicit** `global let` behavior in the some contexts is a bigger and more controversial change
---
### Author:  [@Sukera](https://discourse.julialang.org/u/Sukera)
#### Post date: [October 7, 2020, 4:34pm UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/20 "2020-10-07T16:34:02Z")
> [@lmiq](#):
>
> If I was to interpret this part of the documentation without testing, I would guess that including the file would behave exactly the same as copying and pasting the code into the REPL, but with a warning.
I’m sorry to be blunt, but in that case you must have skipped the [section directly preceding](https://docs.julialang.org/en/v1/manual/variables-and-scoping/#Local-Scope) the [one you’re quoting](https://docs.julialang.org/en/v1/manual/variables-and-scoping/#On-Soft-Scope), since this case is explained in excruciating detail:
So no, I don’t think anything should change here. Just don’t skip part of the documentation and be surprised that something doesn’t work like you think it should.
---
### Author:  [@Sukera](https://discourse.julialang.org/u/Sukera)
#### Post date: [October 7, 2020, 4:37pm UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/21 "2020-10-07T16:37:23Z")
At this point, I don’t think special alias keywords are worth it to disallow `our` and `my` as identifiers (a consequence of your proposal, which would be breaking and thus only be slated for 2.0 at the earliest anyway).
I can only repeat, [Julia is not at that stage of development anymore (click for more infos on why)](https://discourse.julialang.org/t/psa-julia-is-not-at-that-stage-of-development-anymore/44872).
---
### Author:  [@Sukera](https://discourse.julialang.org/u/Sukera)
#### Post date: [October 7, 2020, 4:55pm UTC](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837/23 "2020-10-07T16:55:00Z")
> [@lmiq](#):
>
> “global variables have no spooky effect on the meaning of code that may be far away; in the REPL copy-and-paste debugging works and beginners don’t have any issues”
This is talking about copying a part of a _function from a file_ piece by piece into the REPL and have it work, not the other way around. If your student had copied the code from the REPL into a function instead (as [advised in the very first section of the performance tips](https://docs.julialang.org/en/v1/manual/performance-tips/#Avoid-global-variables)), everything would have worked fine. From my point of view, the current behaviour is (as far as I can tell over the last few years) a global maximum of convenience and ease of teaching.
Put your code into functions, people! Makes stuff easier to test, gives you easy gains in terms of performance, makes your fellow researchers happier, allows more optimizations by the compiler, makes your code less brittle, easier to debug and many more benefits.
[Next page](https://discourse.julialang.org/t/feature-request-and-brainstorming-global-let-issue-37187/47837.md?page=2)