Another possible solution to the global scope debacle

I think the main thing is to have fewer exceptions. Making functions the lone exception is simpler. Also, functions are special in that they indicate an intent to create a reusable piece of code that therefore needs some extra isolation.

I wouldn’t say the purpose of let is to introduce a new scope. Rather the purpose is to create specific new variable bindings. For example this pattern is very useful:

let e = 2.7
    exp(x) = e^x
end

At the top level, having that define a global function exp is what we usually want, and we don’t get it currently (you have to write global).

Another reason is debugging by copying code from functions to the REPL (I confess I do that a lot). In 0.6 it fails only for functions with inner functions. In 1.0 it fails on all scoped constructs. It would be nice to at least go back to everything except inner functions working.

To me, it’s not enough just to guess that since somebody wrote let they want more things to be local. There would need to be a specific, useful code pattern that’s more elegant under that assumption. For example the pattern that kicked off this issue is initializing a variable, and then updating it in a loop. I’m not sure there are any similar patterns that benefit from making more variables local inside let. Given that in general we default to overwriting variables in outer scopes, it can’t be all that important for let to be special here.

11 Likes