Lambda the Ultimate

the two schemes you are comparing are instances of static and dynamic scoping.

one reason for dynamic scoping is ease of implementation. while dynamic scoping requires nothing but a stack of bound variables per identifier, static scoping can be difficult to implement in the context of higher order functions. this particular problem is called variable capture, which you will find at google...

for plain development dynamic scoping is dangerous, as it is not very transparent. it can, though, be very powerful whenever you want to implement custom language constructs (e.g. via scheme macros), where you might have to circumvent static scoping rules.

most languages with dynamic scoping also provide static scoping. everything else seems like a compromise on the implementers side to me. after all, dynamic scoping is the goto of variable bindings...

is here: http://developer.mozilla.org/es4/proposals/block_expressions.html

Without block scoping, the scope gets enriched after a loop which declares a variable, *if there was at least one iteration*. This condition makes the lexical environment runtime-dependent.

That's not true, at least in Javascript: a declaration ("var <name>") doesn't need to be executed to introduce the variable "<name>" in the function scope.

For example, in:

var x = 0;
function f() {
  x = 1;
  if (0) { var x = 2; }
}
f();

The value of x after the call to "f" will be 0, even if "var x = 2;" is never executed. (Incidentally, I find this a little disturbing: you can't simply comment a block of code by putting an "if (0)" around it.)

About "begin" in scheme: I don't see it as much of a problem, as you can always create a new scope with "let". While it's just syntactic sugar for a call to a lambda, I think it is fair to say that it is much more convenient than the javascript equivalent:

(function (x) {
  // use locally scoped x here
)(1);

Or, a little better:

(function () {
  var x = 1;
  // use locally scoped x here
)();

PS: I'm a long time reader, but this is my first post. Back to lurking now... :-)

I don't have any documentation, but I'd guess that ease of implementation is the motivation.

I think I would need to see some real-world bugs from competent programmers before I would classify this as an outright error as opposed to a wart.

But well, with or without block-scope, static analysis is just impossible for dynamic languages anyway..

Well, actually, complete static analysis is impossible for (most) currently available dynamic languages. It's certainly possible, thoug,h to statically analyze them with other degrees of completeness.

This becomes obvious when you comparing dynamic and static typing: the former starts out with basically complete flexibility while the latter is on the other end of the spectrum, but both can be moved towards each other. Of course, by definition, you cannot get static typing from dynamic or vice versa, but you can get pretty close.

As several comments pointed out, my last point is really weak. Indeed, the not-block-scope choice doesn't break static scoping: if x is introduced in an empty iteration, it will still be accessible afterwards. It will be undefined, but no error will be thrown. That's my very problem with this question: the language already being quite weak, it is difficult to explain that some feature makes it weak.

Let's say that unfortunately, this behaviour helps programmers to forget about thinking to a correct default value.