Supporting ECMAScript 2015

[lemmaa]

The General Assembly of Ecma International has announced the approval of ECMA-262 6th edition.

• http://www.infoq.com/news/2015/06/ecmascript-2015-es6
• http://www.ecma-international.org/publications/standards/Ecma-262.htm

Should we need to change our target to support ES6 immediately? or keep going to finish current target first?
Please share your opinion.
Thanks!

[akosthekiss]

I'd argue against re-defining our target unless we are also ready to change our schedule considerably. We are somewhere halfway (a bit better than that) to ES5.1 conformance. We know (and are determined) to reach the conformant status by end of summer/early fall, however I'm sure that ES6 conformance will need quite some extra work. If we change our target now, then we may have an engine at our original deadline which is neither ES5.1 nor ES6 conformant. This will postpone the applicability of JerryScript in real use cases, which can be risky IMHO. I'd suggest going with the original target and setting up a new schedule for reaching ES6 confirmance only after ES5.1 is reached (or very close to that).

[egavrin]

Personally, I appreciate the idea of supporting the latest standard - it's very important from any point of view. But aligning our target with ES6 will definitely require to correct our schedule - it may take time:

• this'd require to study new specification, which is almost 2 time bigger than previous one.
• prepare detailed work plans for our sides and setup workshop to discuss them

I suppose that we'll clarify all plans only by the end of July.

Our current deadlines are very tight and I assume that within them we won't be able to support ES6 fully. If we are not able to reassess current deadline we should continue with our current plans.
Since our final deadline is end of August, I'd consider the following plan:

• Fix our current deadlines to end of August as it was discussed and continues our activities
• Immediately start investigation of ES6 and start preparation of workplans
• Setup workshop at the end of July
  • to discuss our current achievements
  • to discuss ES6 implementation plan that will start since September
  • to define "preparation list" for ES6
• At August, both parties will stabilize their solutions and prepare them for upcoming activity

[sand1k]

I agree with @egavrin.
If deadlines are the same, ES5.1 should be finished first.
But we should start investigation of ES6 ASAP to reasonably estimate efforts for its implementation and be ready for supporting it. 'ES6 compliant' mark sounds good for marketing :)

[zherczeg]

Perhaps we should not forget our other goals, such as memory consumption, performance, binary size. And I also have another goal in my mind: making Jerry a popular JS engine. Creating something which is valuable to others.

[ruben-ayrapetyan]

I agree that it is great to add ES6 support, starting working on it after ES5.1 support would be completed.
Currently, we could start thinking over what need to be introduced / changed to support ES6.

[lemmaa]

@akiss77 @egavrin @sand1k @zherczeg @ruben-ayrapetyan, thank you for having good feedback.
I understand that we all have same opinion, including me.

First, we have to focus our original plan, implementing ES5.1, in schedule. And we also need to start investigation of ES6.

Then let's talk about investigation of ES6.
As of now, @egavrin suggested that workshop from end of July. Is it enough for everybody?
What else we can do? What else we must do?

[egavrin]

@lemmaa since we're going to start optimize Jerry since July, we should take into account new language features and try to avoid engine modifications that may hardener further implementation. Some of them are briefly listed here:

• http://espadrine.github.io/New-In-A-Spec/es6/
• http://es6-features.org/

What we shall do:

• Designate a person who will examine the new standard (it can be me or @zherczeg)
  • This task is quite difficult, so most likely this person will not participate in active development for about 2-3 weeks
• Designated person should prepare detailed list of changes with rough MM estimation per each chapter or change
• Then we'll review the report and prepare more precise estimations
• On the workshop we'll discuss implementation details and assign responsibilities

[kenchris]

I would say at least supporting Promises should be considered, as it is a requirement for most new Web APIs as defined by W3C, WHATWG etc. It is also heavily used by the Generic Sensor API which we would love to support node.js at some point, instead of just web browsers.

Wouldn't supporting "let" instead of just "var", potentially be able to improve memory usage?

[zherczeg]

Supporting promises is probably possible at some point.

Supporting let is very challenging but we might try to do it sometimes.. Lots of engine changes will be required, heavy binary size increase, memory consumption increase, performance drop is expected, so the costs might outweight the gain at the end. So this is not a high priority for us at the moment.

[zherczeg]

I think it is worth discussing the ""let" problem, because somebody might have a good idea to do it efficiently.

In ES5.1, you can simulate "let" in the following way:

// this is the same as: let a = f();
try {
  throw f();
} catch(a) {
}

The catch creates a new lexical environment, which only has one binding, the "a" symbol. This symbol shadows the "var a" symbol (if exists). Hence a new object is created and added it to the lexical environment, which consumes memory and makes resolving slower. You cannot really avoid this because:

function f() {
  var a = 5;
  g = function () { print(a); }
  {
    let a = 6;
    g();
    print(a);
  }
}

This prints 5 and 6.

The other problem is control flow. Statements such as try, with, and for-in create contexts which needs to be destroyed when these statements are finished. Furthermore break/continue/throw/return statements can also abort these contexts. This is done by context breaker gotos whose are much more costly than normal gotos.

Since try, etc. statements are rare, they don't really slow down Jerry at this moment. However, I would assume that people would use "let" much more frequently than those others which would add a lot of context management and would cause considerable slowdown. Telling people that you have "let" but don't use it does not makes much sense.

Hence there are two issues needs to be solved:

• avoid creating extra lexical environments (extra memory for lexical objects, slower resolve)
• increased context management costs (extra memory for contexts, creating/destroying them frequently lowers perofrmance)

And there is a third: we don't have AST and enough time to do complex code analysis. So the solution must be lightweight and must work with little available information.

Let is know if anybody has a clever idea. Otherwise I don't think it is worth supporting "let".

[kenchris]

try/catch might become more popular in ES2017 where async/await are expected for making common promise based code easier to write. This is already in Edge and Chrome (behind flags, I believe)

Btw, the best place to see what goes into future versions is here:

https://github.com/tc39/proposals/blob/master/finished-proposals.md

ES2016: http://www.ecma-international.org/ecma-262/7.0/
ES2017 (WIP): https://tc39.github.io/ecma262/

[kenchris]

As good async support is quite interesting for IoT (AIO might for instance be on another core, like on the Arduino 101), what I would like the most from > ES5.1 would be

• promises
• async/await, which probably depends on generators (can at least be emulated/polyfilled using it)

Did anyone look at how hard it would be supporting these?