Julia: more predictable global binding resolution

[StefanKarpinski]

@JeffBezanson and I discussed this one (a long while ago) and I could have sworn I'd opened an issue about it, but I can't find it so perhaps I didn't. Whether a binding comes from a using or not should be predictable from the content of a module, not what is done with the module. Example:

module A
    x = 1
    export x
end

module B
    using A
    x!(v) = global x = v
end

Currently, we can, in two separate Julia sessions, have B.x either be an import from A or be a global binding from B, depending on what the caller does:

julia> module A
           x = 1
           export x
       end
A

julia> module B
           using A
           x!(v) = global x = v
       end
B

julia> B.x
1

julia> B.x!("bah")
WARNING: imported binding for x overwritten in module B
"bah"

Session 2:

julia> module A
           x = 1
           export x
       end
A

julia> module B
           using A
           x!(v) = global x = v
       end
B

julia> B.x!("bah");

julia> B.x
"bah"

Arguably, the _definition_ of the function x! which assigns B.x should cause B.x not to refer to A.x, rather than the _evaluation_ of x! causing that binding to occur. Thus, in the first case, B.x when occurring before any call to B.x! should be an undefined reference. This may not be worth bothering with, but it could make life easier for static compilation and I really doubt many people are depending on the current behavior. cc @vtjnash

[vtjnash]

Yep, this would make #265 easier.

[StefanKarpinski]

I would fix this in the process of #265 then since I think the more dynamic behavior is undesirable.

[StefanKarpinski]

The flip side of this issue is that if you do using A and don't ever refer to x inside of B then perhaps it should be undefined, as opposed to what we do now, which is lazily populate an bindings acquired via using:

julia> module A
           x = 1
           export x
       end
A

julia> module B
           using A
       end
B

julia> B.x # should maybe be undefined instead
1

This is probably less of a problem, however.

[JeffBezanson]

Yes, we could potentially "seal" the module from bringing in new things visible via using after the module expression closes.

[StefanKarpinski]

An interesting aspect of this is how eval(M, ...) after the module is closed affects bindings. It could only see bindings that are implied by the code syntactically in the module, but what about eval(M, :(newbinging = 123))? I guess in the case of a previously unknown name, that's fine, and if it was previously bound via using and an actual reference, then it could produce the same warning that we emit now.