Intent to implement: ES6 Arrow Function syntax

[Adrian Perez de Castro]

# TC39 acceptance

The arrow function syntax proposal has been accepted to be part
of ES6, and it has been in the ES6 draft specs since May 2012
<http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax>

There has been discussion in es-discuss and TC39 meetings about
arrow-functions and how they interact with the rest of the semantics
of the language, and apart from minor clarifications the proposal has
remained stable along the time. It is very unlikely that the spec for
arrow functions would change in significative ways.


# Interest from other vendors

Firefox/SpiderMonkey already implements arrrow functions since version 22
<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/arrow_functions>


# Technical considerations

Implementing arrow function would have a small impact in V8: most
changes fall in the parser/lexer; the existing representation for
functions would be reused with minor changes.


# Implementation/testing

This patch implements parsing of arrow functions under the
`--harmony_arrow_functions` flag and an unit test for valid
syntax: <https://codereview.chromium.org/160073006/>. After this,
patches would be needed to implement correct scoping of “this”,
“super” and “arguments” in arrow functions (I am working on
those already).


-Adrian

[Dmitry Lomov]

Exciting, and the spec is indeed quite stable.

What are your conformance and performance testing plans?

Kind regards,

Dmitry

[Andreas Rossberg]

On 14 February 2014 18:01, Adrian Perez de Castro <ape...@igalia.com> wrote:
>
> # Technical considerations
>
> Implementing arrow function would have a small impact in V8: most
> changes fall in the parser/lexer; the existing representation for
> functions would be reused with minor changes.

I don't like being the spoil sport here, but I highly doubt this. The
parser extensions are the trivial part. I expect that the different
handling required for 'this' and 'arguments' will have many subtle
implications on runtime support and code generation for both functions
and function calls, and these are deeply engrained, and duplicated
manifold throughout all of V8 and its various back-ends. From our
experience, changes in that area tend to be far more tricky then you
might expect, especially if you need to avoid performance regressions.

In any case, before moving on, please do a more thorough analysis of
how this feature affects various parts of the system, and produce a
design doc sketching the core ideas for an implementation, so that we
can evaluate and discuss it.

Best,
/Andreas