The Temporal Dead Zone, or Why the Typescript Codebase Is Full of Var Statements

  function readfile(name)
    local f <close> = assert(io.open(name))
    return assert(f:read"a")
  end

There are several examples in the blog, and only one is the first. It does not include the "terrible" descriptor after it. So your comment is kind of odd because it doesn't connect to the article at all.

If you mean the first example that's described as "terrible", that's the second example and it's the one with the leaking loop variable. It kind of is terrible, Python has the same problem (and many others, Python scoping rules are not good). C used to have that problem but they at least had the good sense to fix it.

There isn't a difference between lexical scope and "block" scope. What I think you are referring to as "block" scope, is a subset of lexical scope. The difference between var and let/const is where the boundaries of the lexical scope is.

I was really using your comment as a jumping off point for my rant.

I wouldn't describe `var` declarations as lexical, though. Sure, they have a lexical scope that they get hoisted up to cover, but hoisting is not "just lexical scope". It's unusual.

You can't monkey patch lexicals, that is much of their point. Any reference to a lexical variable is a fixed binding.

In practice, this comes up most often for me when I have a script that I want to reload: if there are any toplevel `let/const`, you can't do it. Even worse, `class C { ... }` is also a lexical binding that cannot be replaced or overridden. Personally, I normally use `var` exclusively at the toplevel, and `let/const` exclusively in any other scope. But `class` is painful -- for scripts that I really want to be able to reload, I use `var C = class { ... };` which is fugly but mostly works. And yet, I like lexical scoping anyway, and think it's worth the price. The price didn't have to be quite so high, is all. I would happily take the benefit of avoiding TDZ for the price of disabling hoisting in the specific situations where it no longer makes sense.

I agree that hoisting is a backwards compatibility thing. I just think that the minute optional lexical scoping entered the picture, hoisting no longer made sense. Either one is great, the combination is awful, but it's possible for them to coexist peacefully in a language if you forbid the problematic intersection. TDZ is a hack, a workaround, not peaceful coexistence. (TDZ is basically the same fix as I'm proposing, just done dynamically instead of statically. Which means that JS's static semantics depend on dynamic behavior, when the whole point of lexical scoping is that it's lexical.)

The premise of “a language like Python that works as you describe” is wrong too, since Python doesn’t work like that (it has the same hoisting and TDZ concepts as JavaScript):

  def g():
      def f():
          return x
  
      x = 4
      return f()
  
  print(g())  # 4

  local b
  local function a()
    return b()
  end
  b = function()
    return a()
  end

My solution would only stop hoisting closures that capture lexicals, with the idea that capturing a lexical means that the closure's identity is now tied to that lexical environment anyway so it's kind of bizarre to hoist it out to where part of its identity is missing.

But you were giving a simplified example, so I want to be sure I'm not dismissing your concern unfairly. This would not work:

    function f() {
        return g(); // ReferenceError
    }
    let x = 4;
    function g() {
        return x + f();
    }

    let x = 4;
    function f() {
        return x + g(); // ReferenceError? Unfortunate if so...
    }
    function g() {
        return x - f();
    }

    let x = f(); // ReferenceError
    let y = 2;
    function f() {
        return y;
    }

    let x = 4;
    let function f() {
        return x + g();
    }
    let function g() {
        return x - f();
    }

Isn't that part still the crux of the article as it contains the answer to the title?

Wow! 4 out of 20 total ain't bad!

Jocking aside the starting set (Scala developers) is already small, so it's not like either it or even less Scala.js is going to be a major player anytime soon.