2011-05-09

Eich’s ECMAScript.next status update at JSConf: arrow function syntax, classes, transpilers

Update 2011-06-17: ECMAScript.next: the “TXJS” update by Eich

At JSConf.US 2011, JavaScript creator Brendan Eich gave an update [1] on what features will make it into ECMAScript.next, the version after ECMAScript 5 [3].

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:

  1. My JSConf.US Presentation | Brendan Eich
  2. Google’s Traceur: compile ECMAScript.next to JavaScript on the fly
  3. ECMAScript.next features are taking shape
  4. JavaScript classes
  5. CoffeeScript versus paren-free JavaScript

No comments: