Aligning TypeScript with ECMAScript 6

Topics: General, Language Specification
Jan 15, 2013 at 4:42 PM

So the stated roadmap of TypeScript is to realign with ECMAScript 6 in the next few months. My question is, what ECMAScript 6 syntax has changed that will require changes in TypeScript?

I know this information is available with some digging, but it would be helpful to get a heads up on exactly what syntax we can expect to change.

Thanks.

Coordinator
Jan 16, 2013 at 3:15 PM

It probably could be better said as "realign, if necessary".  There isn't an implication that there will be realignment needed.  We're aware that the ECMAScript spec is still in flux, and the committee could still uncover issues they want to address or syntax they want to improve.  If that happens, we'll also try to align on the TypeScript side for any change that affects the bits of ES6 we've incorporated into TypeScript.

Jan 16, 2013 at 3:17 PM

Ah, ok. Previous comments I had read gave me the impression that there had already been changes to the ECMAScript 6 proposal that would necessitate changes in TypeScript.

Jan 17, 2013 at 7:28 PM

One of the areas where TypeScript is differentiates from the ES6 proposals is the way modules are handled. Especially the import functionality of external modules differ quit a bit. Overall I would say the current ES6 proposal seems more flexible and overall a nice solution (but I guess also a bit harder to implement).

Is this in scope to be realigned or is this ES6 proposal still considered to be too much in flux?

//Peter

Coordinator
Jan 18, 2013 at 4:36 PM

That's right - modules are the biggest area of current disconnect between TypeScript and ES6 - in part because the ES6 modules proposals have been more of a moving target than other parts of ES6.  We're working with the committee, and the champions of the module work in particular, on stabilizing the ES6 design, and then on aligning TypeScript with that. 

Possibly relevant to this thread, I presented feedback from our experience with TypeScript at the ECMAScript working group meeting last November.  Slides from that discussion are at http://sdrv.ms/W21q9e, and notes from the discussion are at https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-11/nov-28.md#experience-with-typescript.

Jan 18, 2013 at 7:48 PM
Luke, thanks for sharing. I wasn't aware the ES6 meeting notes are available online, very insightful. Also a good set of slides, which recaps many of the comments heard on this forum.
However one thing I never really get is the "preference" for the C# await keyword. Once generators have landed in JavaScript, the difference is would be:

await doSomeAsyncStuff(); // Special keyword in TypeScript

versus

await(doSomeAsyncStuff); // Some third party library


Is there something else that I'm missing that the await keyword would bring that a third party library couldn't deliver?


BTW: I hope ES6 isn't going for the @ prefix for private variables.


// Peter


On 01/18/2013 06:36 PM, LukeH wrote:

From: LukeH

That's right - modules are the biggest area of current disconnect between TypeScript and ES6 - in part because the ES6 modules proposals have been more of a moving target than other parts of ES6. We're working with the committee, and the champions of the module work in particular, on stabilizing the ES6 design, and then on aligning TypeScript with that.

Possibly relevant to this thread, I presented feedback from our experience with TypeScript at the ECMAScript working group meeting last November. Slides from that discussion are at http://sdrv.ms/W21q9e, and notes from the discussion are at https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-11/nov-28.md#experience-with-typescript.


Jan 18, 2013 at 9:39 PM

@LukeH - Thanks, that was interesting and useful. I wasn't able to see your slides on SkyDrive, however. I only wish the committee would maybe consider using public/private keywords on modules instead of export. The inconsistency between visibility modifiers on classes and modules drives me crazy.

@jbaroncom - I don't think you understand what the await keyword does (in C# at least). It causes the compiler to rewrite the method into one or more callbacks where the callback is the body of the method below the await keyword. Library-based solutions alone cannot come close to the elegance of this. In fact, the await keyword is complimentary to the use of a promise-based library, not competitory to it.

Jan 19, 2013 at 12:38 PM
@MgSam,

Thanks for the info about C# await functionality. However I didn't mean JavaScript promises or callback kind of libraries versus C# await. I really meant libraries using the ES6 generator functionality (now only available in firefox/mozilla). These libraries are also complementary to promises or callbacks just as the C# await is.

Once these generators land in ES6, you should be able to do similar things as the C# await keyword. You can see an example on taskjs.org how this could work. As far as I call tell:

- Await functionality cannot be implemented without generator support in JS. At least not while still being able to compile to "recognizable" JavaScript. Even the Dart team shied away from this ;)
- Once ES6 generators have landed, the same functionality could also be done with a plain JS/TS library and doesn't require a special new keyword.


P.S One thing where an await keyword could perhaps have the upper hand, is that retaining type information in the compiler is more easy.


// Peter

On 01/18/2013 11:39 PM, MgSam wrote:

From: MgSam

@LukeH - Thanks, that was interesting and useful. I wasn't able to see your slides on SkyDrive, however. I only wish the committee would maybe consider using public/private keywords on modules instead of export. The inconsistency between visibility modifiers on classes and modules drives me crazy.

@jbaroncom - I don't think you understand what the await keyword does (in C# at least). It causes the compiler to rewrite the method into one or more callbacks where the callback is the body of the method below the await keyword. Library-based solutions alone cannot come close to the elegance of this. In fact, the await keyword is complimentary to the use of a promise-based library, not competitory to it.


Jan 20, 2013 at 10:29 AM
Edited Jan 20, 2013 at 10:41 AM

@jbaroncom

Depends on how tolerant you are about JS being "recognizable". I prototyped "await" syntax in streamline.js. The output is polluted by a fair amount of callback handling code but once you abstract that out (I could output comments to ease that) you recognize the original code. Unlike other transforms, the streamline transform does not move code around; it just inserts callback handling logic around it (*).

(*) unfortunately this is not completely true and the transform has to move entire functions around because of hoisting.

Theoretically, async/await can even be implemented in pure JS: . This is not a viable way to do it but the idea is interesting.

Anyway, these are just stopgap solutions. I hope that something similar to the "deferrred functions" proposal will make it into a future version of JS.

Bruno

Jan 20, 2013 at 12:50 PM
@bjouhier,

I guess indeed it all depends on the definition of "recognizable". Your streamline library is a great piece of work and very close to how a developer would write this code (idiomatic code how they like to call it nowadays).

But I believe that many developers have an difficulty wrapping their heads around the concept async programming. So no matter how good the transformation is, they won't understand the result. For example I think many developers would have a hard time writing an async recursive directory walker. So when your library would transform an sync version in to a async version, they also will not fully understand what is going on. That is were generators can abstract through a library and not a transformation and thereby don't dazzle the developers.

BTW, there an example on-line that shows how to "deferred like functions" can be implemented with generators and concurrency as a library.

http://wiki.ecmascript.org/doku.php?id=strawman:async_functions


// Peter


On 01/20/2013 12:29 PM, bjouhier wrote:

From: bjouhier

@jbaroncom

Depends on how tolerant you are about JS being "recognizable". I prototyped "await" syntax in streamline.js. The output is polluted by a fair amount of callback handling code but once you abstract that out (I could output comments to ease that) you recognize the original code. Unlike other transforms, the streamline transform does not move code around; it just inserts callback handling logic around it (*).

(*) unfortunately this is not completely true and the transform has to move entire functions around because of hoisting.

Theoretically, async/await can even be implemented in pure JS: . This is not a viable way to do it but the idea is interesting.

Anyway, these are just stopgap solutions. I hope that something similar to the "deferrred functions" proposal will make it into a future version of JS.

Bruno


Jan 21, 2013 at 8:56 PM

@jbaroncom

I'm completely with you on the difficulty to grasp async programming (I wouldn't have developed streamline otherwise). And yes, generators make it much easier to implement sync-style on top of callback oriented APIs. I actually implemented an alternate backend for streamline that transformes async calls into yield expressions, and I created a small demo (works only in firefox).

I'm a bit concerned about potential performance issues due to the fact that every call must allocate a generator. How costly is this compared to generating a callback closure? How costly is the yield itself? (I'm assuming it is some kind fo longjmp but it can probably be implemented more efficiently in a JS VM). I haven't run any benchmarks as I've been waiting for generators to land into V8 and node. So, if you have hints on this I'm interested.

Bruno

Jan 22, 2013 at 8:09 PM
@bjouhier,

Just played around a bit with the yield demo, nicely done!!! I guess you are right about the possible overhead. But in most JS applications, the async usage is typically course grained. It is not like many applications read from a socket a byte at the time. And even is this were the case, this could still be done with typical callback semantics and abstracted in some class.

I didn't do any real performance measurement. I did some test in the past with co-routines versus callbacks in Lua, but that doesn't really translate to this type of overhead.
Just like you I'm also waiting for generators to land in V8 soon (and other engines) to start playing around with it a bit more. Good thing is that I already saw that someone made a patch to TS to support the required syntax changes. So the playing around with the generators could even be done in TS.

// Peter

On 01/21/2013 10:56 PM, bjouhier wrote:

From: bjouhier

@jbaroncom

I'm completely with you on the difficulty to grasp async programming (I wouldn't have developed streamline otherwise). And yes, generators make it much easier to implement sync-style on top of callback oriented APIs. I actually implemented an alternate backend for streamline that transformes async calls into yield expressions, and I created a small demo (works only in firefox).

I'm a bit concerned about potential performance issues due to the fact that every call must allocate a generator. How costly is this compared to generating a callback closure? How costly is the yield itself? (I'm assuming it is some kind fo longjmp but it can probably be implemented more efficiently in a JS VM). I haven't run any benchmarks as I've been waiting for generators to land into V8 and node. So, if you have hints on this I'm interested.

Bruno