On Thu, Jul 11, 2013 at 2:00 AM, Andrew Fedoniouk
<news at terrainformatica.com> wrote:
> Did we consider green gases emission increase that will happen due to that
>  double parsing of code that currently is parsed strictly once?
>
> ( Consider that rhetoric question above as just a reminder that ES6
>   parser will be used for existing web code when it will deployed for
>   pretty much each connected machine and device ).

Hmm. Well, there is a lot of back and forth in those lines, so I'm not
sure what to make of them. Either the new features are wasteful or
they're not. Pick a position and quantify it. Let's have it out.

I think any argument from energy savings is equivalent to a
performance argument, and in Firefox we would not have landed these
features if they regressed any of the benchmarks we watch. Perhaps it
is relevant that in Firefox, the cost is only paid when an arrow
function or a destructuring assignment is actually used.

In the case of destructuring assignment, we don't rewind and do a
second parse, even if it *does* turn out that you're doing
destructuring assignment. We just have to re-interpret the AST for the
left-hand side that we just parsed as a left-hand side.

Yet another situation where the meaning of an expression changes after
it's parsed is introduced by default arguments, in combination with
strict mode.

    function f(a = function() {...}) {
        "use strict";
        return a;
    }

As I understand it, the function in the default-argument-expression is
strict, but our parser doesn't know it until we hit the "use strict"
directive. In Firefox, this was a bigger pain for us than arrow
functions or destructuring assignment. We rewind and reparse f.

Note that a similar shift in meaning occurs in ES1-5 after you've
parsed `x.y` and then you see `(` or `=` or `++`. When we reach any of
those tokens, we have to go back and check that the left hand side is
valid, and this is nothing to do with any new ES6 features.
(Admittedly, unlike the new features, this is something you can
implement using finite lookahead. SpiderMonkey must have done it that
way, once, before my time. Seems like it'd be messy.)

-j

On Thu, Jul 11, 2013 at 2:00 AM, Andrew Fedoniouk <news at terrainformatica.com> wrote:
> Did we consider green gases emission increase that will happen due to that
>  double parsing of code that currently is parsed strictly once?
>
> ( Consider that rhetoric question above as just a reminder that ES6
>   parser will be used for existing web code when it will deployed for
>   pretty much each connected machine and device ).

Hmm. Well, there is a lot of back and forth in those lines, so I'm not
sure what to make of them. Either the new features are wasteful or
they're not. Pick a position and quantify it. Let's have it out.

I think any argument from energy savings is equivalent to a
performance argument, and in Firefox we would not have landed these
features if they regressed any of the benchmarks we watch. Perhaps it
is relevant that in Firefox, the cost is only paid when an arrow
function or a destructuring assignment is actually used.

In the case of destructuring assignment, we don't rewind and do a
second parse, even if it *does* turn out that you're doing
destructuring assignment. We just have to re-interpret the AST for the
left-hand side that we just parsed as a left-hand side.

Yet another situation where the meaning of an expression changes after
it's parsed is introduced by default arguments, in combination with
strict mode.

```js
function f(a = function() {...}) {
    "use strict";
    return a;
}
```

As I understand it, the function in the default-argument-expression is
strict, but our parser doesn't know it until we hit the "use strict"
directive. In Firefox, this was a bigger pain for us than arrow
functions or destructuring assignment. We rewind and reparse f.

Note that a similar shift in meaning occurs in ES1-5 after you've
parsed `x.y` and then you see `(` or `=` or `++`. When we reach any of
those tokens, we have to go back and check that the left hand side is
valid, and this is nothing to do with any new ES6 features.
(Admittedly, unlike the new features, this is something you can
implement using finite lookahead. SpiderMonkey must have done it that
way, once, before my time. Seems like it'd be messy.)