Let/lambda equivalence

Most call-by-value languages with anonymous functions have let/lambda equivalence: declarations are exactly the same as function parameters/arguments.
((lambda (i j) (* i j)) 3 4)
(let ((i 3) (j 4)) (* i j))

((INT i, j)INT: i * j)(3, 4)
(INT i = 3, j = 4; i * j)

(fn (i, j) => i * j)(3, 4)
let val (i, j) = (3, 4) in i * j end

A related rule is that any expression can be wrapped in a lambda without changing its meaning (besides grouping the expression). Notice how it is the expressions within the lambda bodies that create the scope in which the variables are bound and not the lambdas themselves.
((lambda () (let ((i 3) (j 4)) (* i j))))
INT: (INT i = 3, j = 4; i * j)
(fn () => let val (i, j) = (3, 4) in i * j end)()

One popular language does not follow these rules. Can you guess what it is? It's a language where certain constructs need to be wrapped in functions which are called immediately. It's supposedly ``Scheme-inspired'' but it's statement-based and uses a return keyword. The upcoming version will add a new type of function and variable that does follow these rules, at the expense of having two sets of rules and bloating the language beyond C++.
Give up? It's JavaScript.

>>27
Oh, that's what I was talking about, but you don't need to give the user access to the call chain to do that. I thought you were equating it to what the other fellow was talking about.

On the subject of dynamic scope and recursion, I would love to see a problem that would be best handled by dynamically scoped variables that change value within the recursive call group. I don't believe such a case exists, so I would find it most fascinating.

My use is simple. A library I use maintains some state in a global (for a passable reason), but I need to change that state depending on the task my code is working on. Since I use coroutines, this saves me from having to set it at every point the function is reentered, which would be after every potentially blocking call—and that wouldn't even work, many of those are 3rd party library calls which would do work after blocking, keeping the incorrect value from some other function until they eventually returned to my code where I could finally restore the value.

So in that you need globals that provide some sort of context for execution, dynamic scope has the potential to be genuinely useful.

I recall being convinced of a few other cases. It's usually used for things like redirecting a logger for a given chain of calls. Whatever the case, it probably involves changing the environment for a particular task to execute in.

Anyway, I'll finish off with a horrifying factoid: loops in bash dynamically scope all variables within the loop body. No, you can't turn it off.