`let` syntax weirdness

[Mason]

@cscherrer

Well this just get weirder and weirder. Especially since you get

@Mason

> julia> let
           let
               a = 1
           end
           a
       end
1
> ```

But I get (Julia 1.5)

julia> let
           let
               a = 1
           end
           a
       end
ERROR: UndefVarError: a not defined
Stacktrace:
 [1] top-level scope at REPL[2]:5
 [2] run_repl(::REPL.AbstractREPL, ::Any) at /build/julia/src/julia-1.5.3/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:288

Yeah that was caused by me not being careful when I made that example, sorry. I had defined a above. I was instead thinking of an example like this:

julia> let
           b = 1
           let
               b = 2
           end
           b
       end
2

This is just how local scoping works in julia, it’s the same as functions

julia> function f()
           b = 1
           function g()
               b = 2
           end
           g()
           b
       end
f (generic function with 1 method)

julia> f()
2

[Mason]

@StefanKarpinski

I don’t see it as that weird. It’s using the fact that let creates a local scope to hide a bunch of variables that are closed over. It is not using the ability of let to shadow an existing local binding with a new local binding. In this case there’s little difference since the outer scope is global, there are no outer bindings with those names, and the let block isn’t in a loop or any other structure where creating a new binding on each evaluation would be observable.

Yeah, I mean there’s nothing wrong with it, it’s just not a common pattern people do in package code from my experience, so I see why it can trip people up or confuse them.

[cscherrer]

@cscherrer

Is it correct to say that the first line of a let has hard local scope, and the rest has soft local scope?

Hmm, no this still isn’t right. From the manual:

When x = occurs in a local scope, Julia applies the following rules to decide what the expression means based on where the assignment expression occurs and what x already refers to at that location:

1. Existing local: If x is already a local variable, then the existing local x is assigned;
2. Hard scope: If x is not already a local variable and assignment occurs inside of any hard scope construct (i.e. within a let block, function or macro body, comprehension, or generator), a new local named x is created in the scope of the assignment;

So the first line of a let is “harder than hard”. And the only ways to get this nameless “superhard scope” seem to be

1. Between let and the next newline
2. By using local in the declaration
3. Just gensym all the things

[Henrique_Becker]

@lmiq

Yet one could perhaps expect that let block to result in undefined a anyway, since its scope is local (but since we are not modifying a it is considered as the global a ).

Again, if we are talking about code outside the REPL, then let and for have no differences in this aspect, and having

a = 10
for i in 1:10
     b = a + i
     println(b)
end

to not work because a is not defined in the for would be unnerving. for loops almost always access bindings of the outer scope.

[lmiq]

@Henrique_Becker

to not work because a is not defined in the for would be unnerving.

Yes, of course, it was only that in those artificial examples one might be tricked.

[StefanKarpinski]

The let construct is traditional, but it does two technically unrelated things which would perhaps be better disentangled:

1. Create a local scope
2. Create new bindings for a set of names in that scope

We can imagine a scope ... end construct that just does the first. Then you could translate

let a = 1, b = 2
    c = 3
    # stuff
end

to this:

scope
    local a = 1
    local b = 2
    c = 3
end

So a and b are new locals in the let block no matter what, whereas c follows the normal scope rule: if there is already a local named c it is assigned, if there isn’t then it is created in this scope. Arguably it would be cleaner to keep these orthogonal, but let is traditional and allows you to do both together.

[CameronBieganek]

You may already be aware of this, but the easier way to write

function f()
	a = 1
	b = 2
	c = let
		local a = 3
		local b = 4
		a+b
	end
	(a, b, c)
end

is like this:

function f()
	a = 1
	b = 2
	c = let a = 3, b = 4
		a + b
	end
	(a, b, c)
end

I don’t know if it’s been made clear yet or not, but the purpose of the let block that you linked to in SymbolicUtils.jl is to create closures. The other option is to use global constants:

const d = Dict(1 => 11, 2 => 12)

function foo(x)
    if x > 0
        x + d[1]
    else
        x + d[2]
    end
end

In fact, I’ve been wondering for a while now if there’s any advantage to

let
    d = Dict(1 => 11, 2 => 12)

    global function foo(x)
        if x > 0
            x + d[1]
        else
            x + d[2]
        end
    end
end

over the version with a global constant, aside from reducing namespace clutter. But I guess that’s a little off topic.

[cscherrer]

@CameronBieganek

You may already be aware of this, but the easier way to write

function f()
	a = 1
	b = 2
	c = let
		local a = 3
		local b = 4
		a+b
	end
	(a, b, c)
end

is like this:

function f()
	a = 1
	b = 2
	c = let a = 3, b = 4
		a + b
	end
	(a, b, c)
end

Thanks, yes I’m aware of this. The point was that if we have many bindings or much longer ones, this gets very awkward. The natural solution I could see is to allow let begin. Maybe this could be allowed at some point.

Comma-separated assignments also strike me as strange. But it reminds me a little of named tuples. So I could also imagine being able to do

julia> nt = (a=1,b=2)
(a = 1, b = 2)

julia> let nt...
           a+b
       end

But that doesn’t work today.

[CameronBieganek]

@cscherrer

The point was that if we have many bindings or much longer ones, this gets very awkward.

Just stick to one letter variable names.

[CameronBieganek]

My understanding is that there aren’t many times when you need a let block in Julia. As far as I know, there are two main use cases for let blocks:

• Creating closures at the top-level, like in the SymbolicUtils example.
• Shenanigans where you are creating closures in a while block.

Of course, the other use is just to create a local scope with some local bindings, but given that the Julia style is to write lots of small functions, I haven’t really found myself needing let blocks for that.

[CameronBieganek]

Oh, I just realized there’s a compromise syntax you can use when there are a lot of names you want to bind in a let block:

function foo()
	a = 1
	b = 2
	c = 3
	let a, b, c
		a = 4
		b = 5
		c = 6
		a + b + c
	end
end

[cscherrer]

@CameronBieganek

As far as I know, there are two main use cases for let blocks:

• Creating closures at the top-level, like in the SymbolicUtils example.
• Shenanigans where you are creating closures in a while block.

I had another use case in mind. For metaprogramming, it’s nice to be able to generate code that’s a little more readable. If we’re doing this in a purely functional way, it’s nice to have a guarantee that a generated Expr can be inserted anyway without affecting values outside its context.

@CameronBieganek

…there’s a compromise syntax…

Oh, that’s very nice. Thanks for pointing that out!

[dalejordan]

What’s wrong with:

function f()
    a = 1
    b = 2
    c = let a = 3,
            b = 4
        a + b
    end
    (a, b, c)
end

if your lines get too long?

[cscherrer]

Nice! Didn’t realize you could do that.

[aplavin]

@CameronBieganek

My understanding is that there aren’t many times when you need a let block in Julia. As far as I know, there are two main use cases for let blocks:

Another case when let blocks are helpful is notebooks, both jupyter and pluto. let is a convenient way to have variables local to a cell that don’t pollute “global” namespace.

[cce]

@cscherrer

julia> nt = (a=1,b=2)
(a = 1, b = 2)

julia> let nt...
           a+b
       end

I think this would be an excellent syntax addition. It’s also not something you can implement with macros without introducing type instability, see this discussion thread.

[Henrique_Becker]

Yes, I can confirm this. Basically every cell that I have either:

1. Is not let-wrapped because it only prints or introduce bindings I want to be global.
2. Is let-wrapped to avoid leaking local variables.
3. Is let-wrapped so I can do the following:

new_global_dataframe = let df = deepcopy(raw_global_dataframe)
    # lots of mutating changes over df
    df
end

[simeonschaub]

@cce

I think this would be an excellent syntax addition.

It’s probably unlikely to become syntax, since it’s fundamentally incompatible with how bindings currently work in Julia.

[cce]

@simeonschaub

It’s probably unlikely to become syntax, since it’s fundamentally incompatible with how bindings currently work in Julia.

Simon, do you mind explaining how it’s fundamentally incompatible? I keep learning more about how Julia operates though explanations by you, Steven and so many others.