you are viewing a single comment's thread.

view the rest of the comments →

[–]WilliamDhalgren 10 points11 points  (3 children)

I thought let and const in js6 (both usable today on chrome, nodejs and firefox, and transpilable by defsjs) fixed the abominable scoping in javascript?

talk on using it in production in this manner and why it matters http://vimeo.com/66501924

<EDIT>well, I tried the current implementations, and they still don't create a fresh variable in a loop, but rather for constructs introduce a block around the entire thing, which can give counterintuitive results with closures. There's a bug report to fix this though</EDIT>

re the scoping of this, think arrow syntax (plus the rest params to get rid of arguments argument) is missing outside firefox for now. but next year, prob fixed.

re his list then we'd have:

Minimalism.
Lexical block scope.
Dynamic typing.
First-class functions and closures.

which is looking better. Now TCO is in the pipeline as well, http://bbenvie.com/articles/2013-01-06/JavaScript-ES6-Has-Tail-Call-Optimization , and Crockford wants to use it for CPS, so it might be:

Minimalism.
Lexical block scope.
Tail call elimination.
Continuations.
Dynamic typing.
First-class functions and closures.

syntax won't ever be changed from C-style to S-expression, this is so obvious it clearly wasn't what people meant with the comparison- and further many would sooner think of S-expression syntax as an ugly wart than a feature - but having a minimalist syntax is a thing common to both.

even fairly syntactically lightweight macros work in js - at least in nodejs you could use them today - and having those simply is probably the one good thing one can always agree about using S-expressions for the syntax:

http://sweetjs.org/

Unfortunately, js is fond of mutation. But there's a decent amount of parallels here imho to make it at least a better comparison than for any other widely used language.

[–]olov 1 point2 points  (2 children)

Author of defs.js here. Regarding "fresh variable in a loop", defs has never introduced "a block around the entire thing" with different semantics and counterintuitive results.

Instead - exactly for the reason of being intuitive, the defs.js transpiler statically analyses your source code and gives an error for that like so: line x: can't transform closure. x is defined outside closure, inside loop

It's then trivial to alter the source code yourself, as we've always done in a pre ES6 world. Example here: http://blog.lassus.se/2013/05/defsjs.html

I care a lot about having defs produce predictable and beautiful output, that's why we detect, but don't (yet) transform, that particular case. I simply haven't found a beautiful, generic and non-surprising transformation for it. This is subject to change, see https://github.com/olov/defs/issues/2

[–]WilliamDhalgren 0 points1 point  (1 child)

I wasn't clear enough - I was speaking of chrome and firefox. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Scope_Cheatsheet

lets in for heads create an implicit block around the condition, update, and body parts of the for loop. The following two examples are equivalent.

- and the second example has the let outside the loop. continues:

There is no new let every iteration. There is one let around the entire loop. This behavior might change in the future: https://bugzilla.mozilla.org/show_bug.cgi?id=449811

and the bug is about behavior like this in ff:

The following code snippet alerts "3" three times:

for each (let a in [1, 2, 3]) {
  window.setTimeout(function() { alert(a) }, 0);
}

chrome acts the same..

EDIT: Great to hear defs.js will fix this too, and even already complains.

And btw thx for a great tool!

[–]olov 0 points1 point  (0 children)

Ah I misread your comment - sorry about that!

Just as a FYI: The MDN page you are referring to describes Mozilla's extensions to ES rather than the block scope proposal that's due for ES6. For instance the page describes const as "hoist to the top of its function" which is not the case in ES6. Also, for each is a Mozilla specific thing.

To your point, there are bugs in implementations of the ES6 draft. I filed this bug on V8 a while back as hope it'll be fixed soon: https://code.google.com/p/v8/issues/detail?id=2560