Scoping: blocks allow binding and changing globals without declaring it so

[tonyhffong]

In repl when I do this:

foo = 1
bar() = (foo=foo+1)
bar()

I get ERROR: foo not defined. So far so good.

But if I write it like this:

begin
  foo = 1
  bar() = (foo=foo+1)
  bar()
end

I get 2.

Wrapping it in block changes the behavior. Apparently the bar() inside a block can access foo without declaring it global. And outside the block, I can see foo, so foo is really a global.

[mauro3]

Concerning your last comment, if I understand it correctly: "And outside the block, I can see foo, so foo is really a global.": begin-end blocks do not introduce a new scope, thus this is expected.

[ViralBShah]

The begin-end blocks not introducing new scope is already documented. Not sure what further to do here.

[jiahao]

The challenge is to explain clearly why this happens:

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

julia> begin baz()=(foo=foo+1); baz() end
ERROR: foo not defined
 in baz at none:1

[mauro3]

I think this is a bug! Please relabel this with bug and remove the doc label.

IMO, begin-end block should have nothing to do with scope: they don't introduce a new scope, nor should they modify the scoping rules of containing blocks. However, in this example the scoping rules for the function bar changes from hard-scope to semi-soft-scope (see #10559). Note that the same applies to if-blocks:

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

julia> if true; bar() = (foo=foo+1); bar() end
ERROR: foo not defined
 in bar at none:1

If this is not a bug but a feature, could someone please explain the use case and argue why special-special casing begin-end and if-end blocks is worth the extra language complexity. I plan to update the scope-docs in the near future and resolving this would be helpful.

[ScottPJones]

Definitely looks like a serious bug to me, both for if and begin/end.

[mauro3]

See Jeff's related comment: #10559 (comment)

[JeffBezanson]

Actually this bug might be the evil twin of another "bug":

julia> begin
         local x = 1
       end
1

julia> x
ERROR: UndefVarError: x not defined

This is the good twin because people are ok with this behavior. But the problem is that if begin doesn't introduce a new scope, what is the local x local to? We might want to disallow this.

[ScottPJones]

That just seems like a bug to me, not a "good" one, because if begin/end doesn't make a new scope level, local needs to mean a local in the scope test the begin is in.