4 ms·

> "The return of "soft scope" in the REPL" I'm a little nervous about code in the REPL and code in a file behaving differently. I think they should go back to

> "The return of "soft scope" in the REPL" I'm a little nervous about code in the REPL and code in a file behaving differently. I think they should go back to the 0.x scoping rules everywhere consistently - which was lexical scoping, IIRC. Which brings up a question: if this behavior is context dependent (different in REPL and in a file) does that mean you can set a flag so that code in a file behaves like code in the REPL?

dunefox 6y ago
> Make the REPL behave like IJulia, and Julia versions 0.6 or earlier. > Keep the 1.0 behavior in files, to avoid breaking anybody's code. > Print a warning if code in a file would behave differently than in the REPL, requesting an explicit local or global declaration to disambiguate the variable in the loop.
StefanKarpinski 6y ago
As noted in the rewritten scope docs at https://docs.julialang.org/en/v1/manual/variables-and-scoping/#Local-Scope-1 https://docs.julialang.org/en/v1/manual/variables-and-scopin...: > An important property of this design is that any code that executes in a file without a warning will behave the same way in a fresh REPL. And on the flip side, if you take a REPL session and save it to file, if it behaves differently than it did in the REPL, then you will get a warning. So there's no real danger of deviating behavior unless you're in the habit of ignoring warnings. As to why bringing back 0.x scope rules is not a good idea, this post explains why it was changed in the first place: https://discourse.julialang.org/t/explain-scoping-confusion-to-a-programming-beginner/43206/22 https://discourse.julialang.org/t/explain-scoping-confusion-.... In short, for non-toy programs, it's a significant source of hard-to-find bugs. Also: changing this behavior in non-interactive contexts would violate the semantic versioning compatibility commitment of 1.x releases. Of course, 1.5 does sometimes introduce a warning in existing code, but (a) it will keep working the same way it did only with a warning and (b) this only happens if you had a global implicitly shadowed by a local, in which case there's a large chance your code was actually broken. Give it a try. A lot of time and thought was put into this change and we believe the new design is pretty much locally optimal. It preserves the safety of the 1.0 behavior for non-interactive programming while recovering the convenience of the 0.x behavior in the REPL.
- UncleOxidant 6y ago
  > 0.x scope rules... In short, for non-toy programs, it's a significant source of hard-to-find bugs. It seems like a lot of languages have lexical scoping which IIRC was what 0.x had. (Scheme, Lisp, OCaml are a few examples) Are there aspects of Julia that make lexical scoping particularly problematic? Julia 1.x scoping rules look similar to Tcl's.
  - StefanKarpinski 6y ago
    Julia has utterly standard lexical scoping—and always has. This issue has nothing to do with lexical vs dynamic scoping, it has to do with whether an assignment in a loop clobbers a global (convenient but dangerous) or creates a loop-local variable (safe but sometimes inconvenient). Have you read the linked manual section on scope? It is very clear and explains the design considerations quite thoroughly.
espadrine 6y ago
Julia started with a single scoping algorithm. In v1, they got two (toplevel and function-level). Now, Julia has three distinct scoping algorithms. See the three distinct behavior for the same two pieces of code: Program Ⓐ: l = 0 for i = 1:10 l = i end println(l) Program Ⓑ: local l = 0 for i = 1:10 l = i end println(l) • REPL: Program Ⓐ gives “10”, Program Ⓑ gives “UndefVarError: l not defined”. • TOPLEVEL: Program Ⓐ gives “0”, Program Ⓑ gives “UndefVarError: l not defined”. • FUNCTION: Program Ⓐ gives “10”, Program Ⓑ gives “10”.
- manwe150 6y ago
  I think you misunderstood the v0.x scoping algorithm. In v0.x, there were 3 scoping situations described in the documentation (function, toplevel, and outer). In v1.0, there was essentially 1 (plus clarifications on what a variable was "local" to in various, generally toplevel, situations). Now there are 2, but TOPLEVEL also emits the following warning, that you didn't mention, since it sees the behavior diverges between them: Warning: Assignment to `l` in soft scope is ambiguous because a global variable by the same name exists: `l` will be treated as a new local. Disambiguate by using `local l` to suppress this warning or `global l` to assign to the existing global variable. And while you write "same piece of code", the code you then paste is not the same: the statement "local" appears in a different statement block, leading to it being executed in a subsequent scope block.

dunefox 6y ago

> Make the REPL behave like IJulia, and Julia versions 0.6 or earlier. > Keep the 1.0 behavior in files, to avoid breaking anybody's code. > Print a warning if code in a file would behave differently than in the REPL, requesting an explicit local or global declaration to disambiguate the variable in the loop.

StefanKarpinski 6y ago

As noted in the rewritten scope docs at https://docs.julialang.org/en/v1/manual/variables-and-scoping/#Local-Scope-1 https://docs.julialang.org/en/v1/manual/variables-and-scopin...: > An important property of this design is that any code that executes in a file without a warning will behave the same way in a fresh REPL. And on the flip side, if you take a REPL session and save it to file, if it behaves differently than it did in the REPL, then you will get a warning. So there's no real danger of deviating behavior unless you're in the habit of ignoring warnings. As to why bringing back 0.x scope rules is not a good idea, this post explains why it was changed in the first place: https://discourse.julialang.org/t/explain-scoping-confusion-to-a-programming-beginner/43206/22 https://discourse.julialang.org/t/explain-scoping-confusion-.... In short, for non-toy programs, it's a significant source of hard-to-find bugs. Also: changing this behavior in non-interactive contexts would violate the semantic versioning compatibility commitment of 1.x releases. Of course, 1.5 does sometimes introduce a warning in existing code, but (a) it will keep working the same way it did only with a warning and (b) this only happens if you had a global implicitly shadowed by a local, in which case there's a large chance your code was actually broken. Give it a try. A lot of time and thought was put into this change and we believe the new design is pretty much locally optimal. It preserves the safety of the 1.0 behavior for non-interactive programming while recovering the convenience of the 0.x behavior in the REPL.

UncleOxidant 6y ago
> 0.x scope rules... In short, for non-toy programs, it's a significant source of hard-to-find bugs. It seems like a lot of languages have lexical scoping which IIRC was what 0.x had. (Scheme, Lisp, OCaml are a few examples) Are there aspects of Julia that make lexical scoping particularly problematic? Julia 1.x scoping rules look similar to Tcl's.
- StefanKarpinski 6y ago
  Julia has utterly standard lexical scoping—and always has. This issue has nothing to do with lexical vs dynamic scoping, it has to do with whether an assignment in a loop clobbers a global (convenient but dangerous) or creates a loop-local variable (safe but sometimes inconvenient). Have you read the linked manual section on scope? It is very clear and explains the design considerations quite thoroughly.

espadrine 6y ago

Julia started with a single scoping algorithm. In v1, they got two (toplevel and function-level). Now, Julia has three distinct scoping algorithms. See the three distinct behavior for the same two pieces of code: Program Ⓐ: l = 0 for i = 1:10 l = i end println(l) Program Ⓑ: local l = 0 for i = 1:10 l = i end println(l) • REPL: Program Ⓐ gives “10”, Program Ⓑ gives “UndefVarError: l not defined”. • TOPLEVEL: Program Ⓐ gives “0”, Program Ⓑ gives “UndefVarError: l not defined”. • FUNCTION: Program Ⓐ gives “10”, Program Ⓑ gives “10”.

manwe150 6y ago
I think you misunderstood the v0.x scoping algorithm. In v0.x, there were 3 scoping situations described in the documentation (function, toplevel, and outer). In v1.0, there was essentially 1 (plus clarifications on what a variable was "local" to in various, generally toplevel, situations). Now there are 2, but TOPLEVEL also emits the following warning, that you didn't mention, since it sees the behavior diverges between them: Warning: Assignment to `l` in soft scope is ambiguous because a global variable by the same name exists: `l` will be treated as a new local. Disambiguate by using `local l` to suppress this warning or `global l` to assign to the existing global variable. And while you write "same piece of code", the code you then paste is not the same: the statement "local" appears in a different statement block, leading to it being executed in a subsequent scope block.