CS2 Discussion: Output: Hoisting to block level instead of function level

[coffeescriptbot]

From @edemaine on 2016-12-12 19:43

(This proposal is essentially the "middle ground" suggested by @GeoffreyBooth on coffeescript6/discuss#58.)

I propose that the variable declaration for x gets hoisted to the top of the tightest block where variable x gets assigned, and that variable declaration gets changed to use let, in contrast to the current behavior of hoisting the var declaration of x to the top of the nearest-ancestor function where variable x gets assigned.

The current description of lexical scoping in the documentation seems consistent with this alternate behavior -- it's just that the notion of "scope" has changed:

The CoffeeScript compiler takes care to make sure that all of your variables are properly declared within lexical scope — you never need to write var yourself. [...]
Notice how all of the variable declarations have been pushed up to the top of the closest scope, the first time they appear.

Example

unless quiet
  if good
    message = 'Error'
  else
    message = 'OK'
  alert message

would compile to

if(!quiet) {
  let message;
  if(good) {
    message = "Error";
  } else {
    message = "OK";
  }
  alert(message);
}

Advantages

Most code, like the previous example, will be unaffected by this change, having exactly the same behavior. The only difference is when using closures. In current CS:

for i in [1..5]
  setTimeout (-> console.log i), i*100

compiles to

var i;
for(i = 1; i <= 5; i++) {
  setTimeout(function() { console.log(i) }, i*100);
}

which has the (counterintuitive) behavior of printing 6 five times. Under this proposal, it will compile to

for(let i = 1; i <= 5; i++) {
  setTimeout(function() { console.log(i) }, i*100);
}

which (intuitively) prints 1 through 5. By contrast, to get this behavior in current CS, you would need to use do like so:

for i in [1..5]
  do (i) ->
    setTimeout (-> console.log i), i*100

Limitations

This proposal does not give the programmer control to protect themselves from accidental scoping mistakes. Just like current CS, re-using a variable name in different parts of the code can be catastrophic. With this proposal, you can get different behavior within a function, not just between functions. For example:

for i in [1..5]
  setTimeout (-> console.log i), i*100
for i in [1..5]
  setTimeout (-> console.log i), i*100

compiles to (both in current CS and under this proposal)

let i;
for(i = 1; i <= 5; i++) {
  setTimeout(function() { console.log(i) }, i*100);
}
for(i = 1; i <= 5; i++) {
  setTimeout(function() { console.log(i) }, i*100);
}

which prints 6 ten times. (Actually, it has a race condition. Just like it would in current CS.) However, this bug is relatively easy to fix, either by using different variable names in the for loops, or by assigning to a new variable name like so:

for i in [1..5]
  i1 = i
  setTimeout (-> console.log i1), i*100
for i in [1..5]
  i2 = i
  setTimeout (-> console.log i2), i*100

Personally, I find this very consistent with the current practice of CS, just a little more convenient.

[coffeescriptbot]

From @GeoffreyBooth on 2017-11-25 08:20

Closing per this comment in the original thread. The above only works if we track uses of variables, which isn’t practical in real-world scenarios because of global variables. For example in the first example above, message is used in alert message, and that’s how we know to declare it in that scope; but this is unsafe, as message could’ve been a global variable.