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.

>>31
If you could turn it on for only a few variables, and treat them with the same discretion used with global variables, I could see it working.
That's the idea, in part.

The trouble is that it requires coordination between the function that references the variable and some parent function that happened to initialize the variable.
Nah, you're already using a dynlang. All you need is some context providing information on which variables are dynamically scoped. (You don't even need that, but it makes proper global lookups faster if you know which ones not to chase.)

You might depend on the global variable being changed, but instead some local variable in the middle of the call stack got it, and then was destroyed when it went of scope.
Not really a problem in practice. You normally only scope certain kinds of global variables. If a function changes a variable in dynamic scope, it is the one asserting that all subsequent calls are to be made in that context. Don't worry about what the callee wants, it's what the caller wants (after all, if the callee wasn't asking for external information, it would be using a global variable in the first place.)

You can always get the same power as dynamic scope by explicitly passing the variable down to the child functions through the parameters.
That's debatable on semantics. You'd have to pass down the entire global scope at all times to make it general. And addressing a "globals" (you no longer have true globals, since you can only access them via local reference) requires two dereferences, since this dynamic aspect only works with a collection of references, not the collection of values. I think its entirely unfeasible.

Dynamic scope is not a problem when it comes to voluntary use. Just don't use it when you don't need it and it won't be an issue. And never write anything complicated in bash.