Scoping / shadowing in if blocks

[wsliang]

The following code does not work:

f(a) = a + 1

function g(a)
    if a >= 5
        return f(a)
    else
        f = 0
        return f
    end
end

g(5)

The reason is that the assignment f = 0 in the else block shadows the function f. This seems counterintuitive to me -- I would have expected that local variables created in the else block should be independent from the first if block. Is this the intended behavior, or a bug?

A second related question: is an if block supposed to create a scope block? Right now, the following code works,

function h(a)
    if a >= 5
        b = 3
    else
        b = 4
    end
    return b
end

so it seems like scope blocks are not being created, which is surprising. I found an old post on the mailing list which suggests that it should:
https://groups.google.com/forum/#!searchin/julia-dev/if$20block$20scope/julia-dev/x5PomhH_DsU/XU-VHHdyjXoJ
Could someone clarify the rules? Thanks.

[mbauman]

The rules are fairly well laid out in the manual section on scoping. if does not create a new scope block (perhaps it should be listed as being notable along with begin in the manual), which explains the behavior.

The other thing that's going on here is that the order of the assignment doesn't matter. Any assignment creates a new local variable which is inherited by all its nested inner scopes both before and after the actual assignment unless that variable is explicitly declared global (or local within an inner scope). In fact, you could put the assignment f = 0 after the if block and even though it is effectively 'dead' code and will never be executed, it still makes f local everywhere within the function.

The manual has some examples about why this is a nice thing, but the first time I ran into it, I found it surprising, too. See also #4645.

[wsliang]

Thanks for the explanation. So I guess what I should have asked is: "why don't if statements create new scope blocks?" It seems this was the behavior in the past (see the referenced mailing list post); what changed?

[mbauman]

I can't speak to if it ever was that way or why it changed, but I can say that I've found I prefer it this way. It still gives me pause when I depend upon it, but then I'm grateful that I didn't need to explicitly write local in the scope above the if statement. Explicitly writing local is discouraged, and it's not uncommon to introduce variables in if blocks… particularly in code coming from Matlab as there is no ternary operator (and minimal scoping).

Another reason may be that the ?: ternary syntax is simply sugar for an if-else expression. I wouldn't expect new scope blocks there, and it's nice to have exactly the same semantics.

It is interesting, though, and I think pretty unique… are there any other languages that create new scopes in for and while but not if?

[StefanKarpinski]

As far as I can recall, if has never introduced a scope block in Julia. I'm not sure about other languages.

[nolta]

As far as I can recall, if has never introduced a scope block in Julia.
I'm not sure about other languages.

Didn't they? I still instinctively write code like:

local a
if ...
    a = ...
end

[StefanKarpinski]

I don't think so, but @JeffBezanson will remember.

[Keno]

Yes @nolta I do the same, so there must be something to it.

[cmundi]

The first time I encountered this, I did RTFM, and I thought, "This is perfectly self-consistent and is also going to lead to numerous programmer errors." The order-independent shadowing (presumably) enables compile-time optimization but clashes with the (arguably dangerous) expectation of causality many of us bring from long experience with languages in which imperative is synonymous with immediate. I admit I don't have a better idea, but I personally try to avoid binding to outer scope as much as practical.

[JeffBezanson]

I have the same reaction as Stefan; I don't think if statements ever introduced new scopes.

I question whether the "strict imperative" interpretation is really more intuitive:

print(f)  # refers to outer `f`
f = 0  # creates new variable
print(f)  # refers to new `f`

if randbool()
    f = 0
end
f  # randomly refers to inner or outer `f`

I contend that it's highly debatable whether those behaviors are better than what we do. I don't think our scoping is just a hack to make the compiler's life easier; I think it makes variable scope more robust and predictable.

[toivoh]

FWIW, also in python a variable in a function will be visible in its whole
scope block, not just after it has been introduced. (Very few things in
python introduce scope blocks, btw, primarily functions I think)

On Sat, May 17, 2014 at 7:11 PM, Jeff Bezanson [email protected]:

I have the same reaction as Stefan; I don't think if statements ever
introduced new scopes.

I question whether the "strict imperative" interpretation is really more
intuitive:

print(f) # refers to outer f
f = 0 # creates new variable
print(f) # refers to new f

if randbool()
f = 0
end
f # randomly refers to inner or outer f

I contend that it's highly debatable whether those behaviors are better
than what we do. I don't think our scoping is just a hack to make the
compiler's life easier; I think it makes variable scope more robust and
predictable.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6872#issuecomment-43415546
.

[cmundi]

@JeffBezanson - Although you didn't call me out by name, I hope it was clear from my note that I was not suggesting that Julia scoping is a hack of convenience. I was serious about the scoping being potentially advantageous for optimization over whole-function scope.And as I said, I don;t have a better idea. I do know from having implemented a few commercial DSLs (i.e. with paying customers) with different scope semantics that this choice (which @toivoh points out is not new) actually does surprise a surprising number of people. (This matters when you're supporting a commercial product, as it correlates strongly with the frequency of support calls. )

To be clear, I'm not advocating for a change. As I said before, the rule is perfectly consistent and clearly documented. But like any design choice it has consequences and as I said I don't have any better advice except the old saws that make it hard for errors to hide: avoid globals; use descriptive names; keep functions short.

[stevengj]

I don't think you want to create new scope blocks in an if. You want to be able to write code like:

if condition
    x = 3
    y = 4
else
    x = 7
    y = 5
end
...do something with x and y....

without having to explicitly declare x and y, return a tuple from the if block, or something similarly awkward.

[cmundi]

Agree. Creating new scope for "if" would be just weird. I mean, where would
it end? I could define a language in which every if/elif/else block created
a scope but that would be just wrong. :) Apologies and condolences to
anyone who has actually done that...
On May 18, 2014 4:20 PM, "Steven G. Johnson" [email protected]
wrote:

I don't think you want to create new scope blocks in an if. You want to
be able to write code like:

if condition
x = 3
y = 4
else
x = 7
y = 5
end
...do something with x and y....

without having to explicitly declare x and y, return a tuple from the ifblock, or something similarly awkward.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6872#issuecomment-43456772
.