New scope solution

Internals & Design
36

This proposed solution bears a striking resemblance to escape analysis, which is a tricky beast but also key to some seriously powerful compiler optimizations. It is also, notoriously, the one optimization that Java can still not perform (well). I bring this up because I think it is worth considering the fix to this “bug” in the larger context of escape analysis.

Java has problems with escape analysis not only because it is a difficult optimization to perform, but also because the language was not designed with it in mind. With Julia, we have the opportunity to evolve the language in a way that would facilitate escape analysis.

I think the crux of the scope “bug” is the desire to create strongly bounded scopes. We want this because it simplifies escape analysis. If we state that any variable created within a for loop, or within a function, falls out of scope at the conclusion of the loop or function body, unless returned, then we only need follow the path of explicit returns to perform escape analysis. However, if some value within one of these scopes is assigned to a global variable then we must consider multiple escape routes. Consider, for example:

b = []
function foo()
  global b
  for i = 1:10  
    append!(b, i)
  end
end
foo()

There are, in this function, 10 values that have escaped the function scope. Still, because we must specify global b, analysis is relatively straightforward. The more complicated the rules become for determining when a variable might escape a scope, the more difficult it becomes to perform escape analysis.

The REPL throws a monkey-wrench into all of this, as it is essentially a never-ending function call. Nothing can escape the REPL, so we would like to relax some of the constraints around escape analysis in the name of “user experience”. The problem, of course, is that the REPL is not a function call.

In short, I am not in favor of this proposed solution because of how it potentially complicates escape analysis. I do think, however, that it highlights one potential path toward a more general solution. What if, instead of tweaking the rules for how variables might, or might not, escape from an inner scope, we allowed for outer scopes to explicitly opt out of variable escaping? In other words, what if you could do the following:

module Foo
  locally_scoped() # => this call alters the scoping rules of the module
  b = []

  function bar()
    for i = 1:10 
      append!(b, i)
    end
  end

  function baz()
    @show b
  end
end

Foo.bar();
Foo.baz() # => 10-element Array{Any,1}: 1, 2, ...

This way, the REPL could evaluate in a module context wherein every variable is considered locally scoped, but we can still preserve the ability to perform escape analysis (in every other module).

3 Likes