New scope solution

proposal

#124

I’d be happy to just have it in scripts, really :slight_smile: But I guess it’s not really a feasible solution.


#126

Just a question, not a proposal, request or suggestion.

Many other languages don’t have this issue because they require you to write var, let, type or def in front of every variable. Why was the design decision made in Julia to not use this approach?


#127

I also have the same question … i.e., if declaration and assignment can be distinguished syntactically, things seem much simpler
(like a := 1.0 vs a = 1.0 in Go), while not tedious to write. It can also help
avoid possible errors due to typo of variable names (e.g. unintentional declaration
of new variables).


#128

I don’t know the history, but I think this was a choice between making the syntax more verbose or dealing with the consequences of occasional ambiguity. Since many languages, especially interactive ones, no longer require explicit declarations of new variables, users are now expecting this.


#129

Context: I am a professional programmer now, but I started as a hobbyist and have no formal CS background, and I’m just getting started with Julia.

A few thoughts:

  • I thought the scoping rules in the loops in the REPL in 1.0 were weird. I read the docs. Now, I think they are fine, if a little inconvenient for interactive use. The thing I thought was weird is that using an accumulator pattern works inside of a function, but doesn’t work the same way in the global scope. However, it’s fine, once you understand that, in terms of scope, a loop block is the same as a function block.
  • I had to read over the current proposal’s rules (the rules I quoted) several times before I could begin to visualize how they would work. That’s probably not great. My feeling is that a rule like this would add extra cognitive overhead when reading code–and that’s definitely bad–even if it’s not so difficult for the compiler.
  • From the discussion, I’m not sure if this stuff only applies to loops outside of functions or what. The worst possible case is if global state could be implicitly modified from inside functions as a consequence of the changes being proposed. The alternative is also weird: different behavior inside and outside of functions.

If we can’t keep the current behavior, which is my vote, why not just have loops inherit values from the outer scope (which would be the global scope, in this case), similar to the way they inherit the outer scope in a function or other scoped block? I guess that means scope would mean one thing in function blocks and another thing in loop blocks, but that seems to be how most languages handle it.

I have one request, whatever happens:

Please do not change the way scoping works inside of functions. It’s already perfect. I don’t really care what you do with global scope, since I don’t put mutable things in it (except in the REPL, but I don’t mind having to write global a few times if I need to).