> let's assume that `Val` is an argument to the current function in which `SumFun` is defined, and so the compiler cannot reason about the actual value that was bound.
That was exactly the case I was talking about, because otherwise there is no need to even make arity 2 function. If the value is known at compile time, the constant is embedded into the body of inlined function.
>At runtime, when the closure is executed, the underlying function receives the closure environment, from which it loads any free vars.
To my understanding, no it doesn't, as the value is resolved when the function pointed is created, not when the underlying function executes, which the code you linked shows too. I know it uses the "env" as a structure field, but it's partial application, not the actual closure which has access to parent scope. Consider two counter examples in python:
for x in range(1,10): ret.append(partial(lambda y: y*2, x)) # that's what erlang does
for x in range(1,10): ret.append(partial(x, lambda y: y*2)) # that's an actual closure, as all lambdas will return 18 because x is captured from the parent context
But then again, it doesn't matter since variables are assigned only once.
>Like I mentioned near the top, it's worth bearing in mind that the compiler can also do quite a bit of simplification and optimization during compilation to BEAM - so there may be cases where you end up with a function capture instead of a closure, because the compiler was able to remove the need for the free variable in cases like your example, but I can't recall what erlc specifically does and does not do in that regard.
I was looking into it a week ago, and erlc does what I described when it can't figure out the constant at compile time.
add: If we are at it, BEAM doesn't even know about variables, only values and registers anyway, so it has nothing to capture anyway.