I see that the Julia community are currently debating on the new scope rules in v1.0, in an attempt to return to the deprecated soft/hard local scopes in v0.6. In my opinion, neither solution is ideal. Here, let me give my thoughts from a teacher and data scientist’s perspective. In the following, I will
- illustrate the mechanism of hard/soft local rules,
- explain why neither solution is ideal, and
- propose the removal of the soft scope.
The mechanism can be illustrated in the following two figures:
The Global scopes view each other through
import. The local scope and the nested local scope communicate with each other freely (in absence of the
local keyword). The difference between the hard local and the soft local is that the hard one can only view the global variables (in absence of the
global keyword) while the soft one can also modify them.
Some users complained that the distinction between the hard local and the soft local is too complicated, so
v1.0 replaced every soft local with the hard local. Now, other users are complaining the omnipresent
global keyword is too awkward, so we are returning to
Neither solution is easy to teach. The hard/soft one needs to explain why some local variables cannot modify global variables; the all-hard one needs to explain why the
global keyword has to be in every loop. Both are counter-intuitive.
Neither solution supports code copying between prototyping and developing. The global/soft local duality is not equivalent to the hard local/nested local duality. The all-hard setting needs to remove all
global when copying code into functions. Both are annoying.
It seems that we all forgot another (obvious) solution: instead of replacing the soft local with the hard one, we can alternatively replace it with the global scope. Then the prototyping environment will be equivalent to the development one.
The hence simplified version will be easy to teach and convenient for copying code. Indeed, it will make it much like Python. Everyone will be happy. If this does not cause any performance issue, I believe that it will be the best solution.
The only downside I can think of is the emerge of many global variables, which can 1) pollute the global scope and 2) be visible to other modules. The first problem can be easily solved by taking caution in the naming of the various variables with long or short lifespan; the compiler can even rename it internally.
The second problem is only annoying when using editors’ auto-completion feature after tying the module name as the qualifier. It can be solved via some keyword like
export, which makes it invisible via the module qualifier, and this kind of device is much easier to teach than the loop awkwardness taught at the beginning.