search

maxtaco / coffee-script

IcedCoffeeScript
http://maxtaco.github.com/coffee-script
MIT License
727 stars 58 forks source link

Making Iced CoffeeScript compatible with ES7 #157

Open osyed opened 9 years ago

osyed commented 9 years ago

Future versions of JavaScript will be providing the await/async keywords to simplify asynchronous coding. http://code.tutsplus.com/tutorials/a-primer-on-es7-async-functions--cms-22367

So eventually await/async will be part of coffeescript. Unfortunately all the programs we've written in iced-coffeescript using the await/defer pattern will not be compatible. It would have been nice if iced-coffeescript has used the await/async pattern so that it would eventually be compatible with a future version of coffeescript.

It is possible to use the ES7 await/ascync keywords now using pre-compilers like nodent. https://www.npmjs.com/package/nodent So it seems the await/async features can be provided with current versions of JavaScript.

Changing iced-coffeescript to support this pattern would be a breaking change with previous versions of iced-coffeescript. It would probably need to be a top level version change or another fork of coffeescript. Perhaps the new version of iced-coffeescript would serve a very useful function of providing upcoming features of JavaScript before they make it into coffeescript.

maxtaco commented 9 years ago

I prefer our semantics to ES7's, but of course don't want to be in the business of indefinitely rewriting the AST to hack coroutines. My current thought is to reimplement ICS using ES6's yield. That would significantly streamline my fork to CS, and will probably make for better performance and debuggability. More brainstorming here on that.

So probably I'll strip out CS's emission of await when ES7 comes, and stay with our semantics. That was my current thinking, at least so we can keep all of the existing ICS code that we have running properly without having to rewrite it.

osyed commented 9 years ago

I also like your semantics over ES7's. It does not require having to add the "async" keyword before every asynchronous function. Since ES7 has not been finalized yet, have you considered proposing your semantics to the spec writers. It would be super if they opted to go with await/defer instead of await/async. https://esdiscuss.org/

maxtaco commented 9 years ago

Thanks @osyed, unfortunately, I am busy enough at my day job that I can't really carve out much time for this. If someone wanted to champion the cause, I'd be happy to throw in support though.

osyed commented 9 years ago

I totally understand.

I came across this meeting note on async/await got to it's current status: https://esdiscuss.org/notes/2014-01-30#async-await

One thing I'm a bit confused about with the async/await pattern is how it deals with pre-existing asynchronous functions. For example a library or module that provides an asynchronous function. Would it require writing your own wrapper around it to add the 'async' keyword so that your wrapper can then be called with the 'await' keyword? The await/defer pattern does not have this issue and can easily handle pre-existing asynchronous functions.

bishtawi commented 8 years ago

Any update on this?