Add yield support #3073

Closed
gunta opened this Issue Jul 19, 2013 · 30 comments

Projects

None yet
@gunta
gunta commented Jul 19, 2013

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
Collaborator

+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
gunta commented Jul 19, 2013

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
Collaborator

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

@gunta
gunta commented Jul 19, 2013

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
Collaborator

@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. #2638, #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
Owner

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
Collaborator

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
Owner

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
helmus commented Nov 7, 2013

+1 !

@Artazor
Artazor commented Nov 14, 2013

+1 for yield

@fheisler

+1, please yield!

@stephenhandley

+1 yield

@vendethiel vendethiel closed this Dec 20, 2013
@vendethiel
Collaborator

We have a PR for that

@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
let4be commented Jan 26, 2015

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 notifications@github.com:

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)
.

@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
Collaborator
lydell commented Jul 15, 2016

@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. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment