Scoping issue in let-block

[mauro3]

This is a bit odd:

               _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "help()" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.0-dev+5511 (2015-06-22 05:05 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 1e081b7* (0 days old master)
|__/                   |  x86_64-unknown-linux-gnu

julia> bar() = (foo=foo+1);

julia> let foo=1; bar() = (foo=foo+1); bar() end
ERROR: UndefVarError: foo#8293 not defined
 in anonymous at no file:1

julia> let foo=1; bar() = (foo=foo+1); bar() end
2

May have something to do with #11801.

[Sisyphuss]

I think it is another bug. Even in v0.3.9, I have already this problem.

[mauro3]

Yes, you're right.

[JeffBezanson]

This example should shed some light:

julia> f() = 0
f (generic function with 1 method)

julia> let
             foo = 10
             f() = foo
             f()
          end
0

julia> f()
10

Basically, adding a method to a top-level function is not guaranteed to take effect until the next top level expression. It's not really a scope issue per se. I'm positive there is another issue about this somewhere, but I haven't been able to find it yet.

[ScottPJones]

What's the reason behind that lack of a guarantee about when it takes effect?

[yuyichao]

@JeffBezanson Is this some manifest of #265.

julia> f() = 0
f (generic function with 1 method)

julia> function g()
       foo = 10
       global f
       f() = foo
       f()
       end
g (generic function with 1 method)

julia> g()
0

julia> f()
10

julia> g()
0

[JeffBezanson]

It's related to #265, but IMO we could fix #265 without changing this behavior. Fixing #265 involves, essentially, invalidating and updating various caches, but there is still a question of when those changes become visible. The problem here is that for f() = foo to take effect immediately, we'd have to update code that is currently running, which is much harder and not as important in practice. After #265, I'd expect this result:

julia> g()
0

julia> f()
10

julia> g()
10

[ScottPJones]

Is there any way for the compiler to realize that it is calling something that has been modified previously in the same scope, and maybe generate different code, to handle picking up the new definition?

[simonster]

@JeffBezanson Maybe you're thinking of #4688 (comment)?

[JeffBezanson]

Yes!

[Sisyphuss]

adding a method to a top-level function is not guaranteed to take effect until the next top level expression.

It's a feature or an issue?

[mauro3]

This seems to be working now:

   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.5.0-pre+5610 (2016-07-22 07:51 UTC)
 _/ |\__'_|_|_|\__'_|  |  m3/function_module/58ca87b* (fork: 1 commits, 0 days)
|__/                   |  x86_64-pc-linux-gnu

julia> bar() = (foo=foo+1);

julia> let foo=1; bar() = (foo=foo+1); bar() end
WARNING: Method definition bar() in module Main at REPL[1]:1 overwritten at REPL[2]:1.
2

julia> let foo=1; bar() = (foo=foo+1); bar() end
WARNING: Method definition bar() in module Main at REPL[2]:1 overwritten at REPL[2]:1.
2

Close? Or is it worth to keep it open for the general issues discussed here?

[mauro3]

Note that Jeff's example #11808 (comment) also works now:

julia> f() = 0
f (generic function with 1 method)

julia> let
                    foo = 10
                    f() = foo
                    f()
                 end
WARNING: Method definition f() in module Main at REPL[1]:1 overwritten at REPL[2]:3.
10

[mauro3]

This is all working with 1.0 scoping rules. Closing.