Add yield support

[gunta]

I know that the policy was not new adding new ES6 features.

But now, it's 2013,
and the latest V8 and Node.js 0.12 supports yield,
which is one of the best features to prevent callback hell.

We should add support for it, because it really improves the current situation of callbacks spaghetti in Node.js.

Thank you.

[michaelficarra]

+1. I've been meaning to open an issue for support of all ES6 features. It raises the question of whether we want to adopt the ES6 syntax/semantics for features that we've introduced separately, for example list comprehensions and super. But no such problems exist with adding yield. I'd prefer to wait until the final draft of ES6 has been released, still, before including any of its features. That and I wouldn't want to include them in a 1.x version of the compiler.

[gunta]

What about having a --harmony flag?

It would follow the Node.js and V8 practices,
and it makes sense because people writing code for Node.js usually want to try latest features because the code is not tied to old browsers.

[michaelficarra]

What do we do when ES6 is finalised and we want to make these features official? Have --harmony be a meaningless flag?

[gunta]

It is going to take some years to be outdated so I don't think it's meaningless and neither does the V8 and Node.js team.

Because it is the only way to test forward the advance in JavaScript.
After all, after the ES6 spec is finished, there will be also ES7 and ES8.

[michaelficarra]

@jashkenas: I'd really like to get your input on this, especially my first comment above. I feel pretty strongly that CoffeeScript needs to evolve or die, and also prefer that it remain a simple enhancement over what you can do with the latest version of ECMAScript (sans anti-features like with and getters/setters of course). This doesn't necessarily mean dropping our ES3 compilation target. We should be

• adopting the syntax/semantics of ES6+ features that already exist in CoffeeScript (eg. Make super consistent with ES6 #2638, List comprehensions: brackets vs parens #1340)
• adding features introduced in ES6+ that can be emulated in ES3
• deciding how to handle features that can't be compiled to <ES6

That last point's going to be tough. I don't want a separate ES3-target, ES5-target, and ES6-target compiler, and I'm sure you don't either. I think we should consider a flag like the suggested --harmony to allow usage ("pass-through") of ES6 features that we can't support with an ES3 target.

[jashkenas]

Agreed. I think that we should start considering the new features as soon as they begin to work in browsers, and on Node.

Ideally, it'll continue to be a single target compiler, and your output JS will simply be ES3-incompatible if you use ES3-incompatible features (as it already is if you [].map(), for example). Features that aren't backwards compatible need to be clearly documented on the homepage.

I think that evaluating and implementing these things as they arrive, is a fine way to get started. Yield is probably a good one to begin with.

[michaelficarra]

Just to be clear, that means you also support the syntactic and semantic changes needed to bring CS in line with ES6? Should I reopen #2638 and #1340?

edit: Also, this should obviously wait until 2.0 or replacing this compiler with CSR.

[jashkenas]

that means you also support the syntactic and semantic changes needed to bring CS in line with ES6

No, not necessarily. Just like CoffeeScript's semantics don't perfectly match ES3's. I think that our current super is nicer than ES6's, by a long shot ... and I think that for loops should continue to be meaningful expressions as maps and filters, if you use them as such.

Regardless, classes, super, and comprehensions aren't shipping in V8 just yet, are they? Aren't they still in flux?

[aaronshaf]

"Agreed. I think that we should start considering the new features as soon as they begin to work in browsers, and on Node."

This is really encouraging!

[EndangeredMassa]

I've gone back and forth on this in my head. I think that the Ideal CoffeeScript is one that targets ES6 (with CS syntax and minimal semantic updates) and compiles to ES3 or ES5. However, I don't think that changing some things like super and comprehensions is a great idea at this point.

So, I agree with the progressive approach. Starting with yield/generators sounds perfect because it's already being used in several interesting libraries.

[monolithed]

+1

[sircambridge]

+1 yield pretty please

[helmus]

+1 !

[Artazor]

+1 for yield

[fheisler]

+1, please yield!

[stephenhandley]

+1 yield

[vendethiel]

We have a PR for that

[xixixao]

#3240

[let4be]

For those who continue to struggle:
http://stackoverflow.com/questions/24700210/how-to-enable-coffeescript-harmony-support/24705455#24705455

[socketpair]

I did not understand, is yield supported or not now.

[monolithed]

You do not understand.
We have the operator %%, which is much more important and useful 😜

🐎

[socketpair]

@monolithed, your joke is not relevant. Please write on the case.

И таки да, шутку не оценил, лучше бы про yield сказал по делу.

[monolithed]

@socketpair, try ES6

[bjmiller]

Generator support now exists on master, and will go out with the next major release.

(Unless I'm missing something?)

[let4be]

You are missing ES6, why would you need to use outdated coffee when you can
use ES6 generators with traceur or 6to5? ;)
classes, modules, arrow function and many else

2015-01-26 17:04 GMT+03:00 Brian Miller [email protected]:

Generator support now exists on master, and will go out with the next
major release.

(Unless I'm missing something?)

—
Reply to this email directly or view it on GitHub
#3073 (comment)
.

[bjmiller]

#3162 (comment)

[MattKunze]

Bummer, seems like there's no support for yield* - we've started using redux-saga and it's been working great, but just came across a case where yield* made things a lot simpler and had to escape it with backticks.

[lydell]

@MattKunze yield* is called yield from in CoffeeScript.

[MattKunze]

Awesome, thanks! Somehow missed that in the docs

[foxbunny]

Agreed. I think that we should start considering the new features as soon as they begin to work in browsers, and on Node.

@jashkenas Do you think it would be unreasonable to target Babel and similar with CS output, rather than the 'bare-metal' runtimes? Cause that's kinda what I was contemplating. :)