Eich’s ECMAScript.next status update at JSConf: arrow function syntax, classes, transpilers
Probably in ECMAScript.next
- Array comprehensions
[a+b for (a in A) for (b in B)]
- Support for binary data
Advocated by Eich
Arrow function syntax is a compact way of writing functions, that replaces the more verbose function(x) { return x; } with (x) -> x. Eich mentions that he regrets not having used fn instead of function for the function-defining operator. But that choice cannot be revised, because there would be clashes with all existing programs that use fn as a variable name. // Primary expression body needs no parens or braces
let identity = (x) -> x;
// Exception: object initialiser must be parenthesized, see below
let key_maker = (val) -> ({key: val});
// Nullary arrow function starts with arrow (cannot begin statement)
let nullary = -> (preamble + ': ' + body);
// Lower-precedence expression body needs parens
let square = (x) -> (x * x);
// Statement body needs braces (completion return TODO)
let oddArray = [];
array.forEach((v, i) -> { if (i & 1) oddArray[i >>> 1] = v; });
// Use # to freeze and join to nearest relevant closure
function return_pure() {
return #(a) -> (a * a);
}
A prior proposal suggested using the sharp symbol # to start a function definition, but that symbol has now been rededicated as an immutability operator. It turns objects into records (immutable, simpler) and arrays into tuples (immutable, simpler).
Classes: Eich argues that better syntax for type definitions should be introduced. I am glad to hear this, because it is an essential feature for improving tool support for JavaScript. The term class has been frequently used at JSConf for this kind of improvement and caused a lot of controversy [4], because people were (justifiably) scared that JavaScript’s inheritance would be completely overhauled. But it makes sense to use that term, because people immediately make the right associations (a class has instances, etc.). However, classes in JavaScript won't be much more than syntactic sugar for what is already there.
Transpilers: were a big topic in the talk and at the conference. They are compilers that translate from a source language to JavaScript, often on the fly, dynamically. Transpilers greatly help with exploring new language features before they become part of ECMAScript.next.
- ES.next modules support dynamic transpilation.
- CoffeeScript [5] does static transpilation.
- Traceur is a new ECMAScript.next transpiler from Google. Eich had some reservations about how Google developed Traceur [2].
- Coming to Firefox: debugging the original source code.
Miscellaneous candidates: Paren-free [5] is still in the cards; more operators.
Related reading:
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)





