Hi Ben,

Sorry for the very late response.
This is quite an interesting work, thanks for sharing!
I'm particularly interested in your test suite [1] which is impressive.

This is making me realize that generators are fully compilable 
(efficiently from what I can see) into ES5 and makes me wonder if the 
current generators specificities are worth it. Very specifically, do we 
really need Generator.prototype [ @@toStringTag ] === "Generator" ?
 From an author point of view, I don't really see in which situation 
this information could matter. As a comparison, functions generated 
after the class syntax do not have an @@toStringTag to "Class".
Generators would just be sugar to write iterators (+ .throw)


Le 03/11/2013 21:55, Ben Newman a écrit :
>
>   * Given that this tool will become obsolete as more and more engines
>     implement ES6 generator functions, how can we maximize its value
>     in the meantime? Are there grey areas in the draft spec that can
>     be illuminated? Should I spend my time implementing (or getting
>     others to implement) await syntax and/or control-flow libraries
>     that leverage generator syntax?
>
You can most certainly experiment with await syntax and share what 
you've learned.
Are there any test cases that you've written and you feel like the 
expected spec behavior is odd or unintuitive in some aspect?

>   * How would you design a system that selectively delivers transpiled
>     code to ES5-capable browsers and native generator code to
>     ES6-capable browsers, so that end users will benefit immediately
>     when they upgrade to a browser with native support for generators?
>
Since there is no semantic difference between the ES6 and your compiled 
version, it's unlikely the users will see a difference at all (not even 
sure the perf is that much different).

But if you really want to try there are different options with 
different  downsides.
1) Server-side UA sniffing. You get the User-Agent header, infer which 
browser it is and decide which version you should be sending. Send the 
ES5 version when you don't know the UA (safe default)

Downsides:
* if a browser changes its header, you may be sending the wrong version. 
This is a problem when you're sending the ES6 version to a non-ES6 
browser (which admittedly should be a very rare case)
* You need to update the list of ES6 User-Agent strings as new browsers 
arrive

2) Send a feature-detection JS snippet on the client which will decide 
which version to load.

Downside:
* having to wait until this snippet is executed to start code download 
(or one extra round-trip if code was originally inlined)

3) send compiler to the client-side

Downside:
* more code

Personally, I'd go for sending the ES5 version to everyone. My second 
choice would be 1), but I guess it depends on the requirements.

David

[1] https://github.com/facebook/regenerator/blob/master/test/tests.es6.js
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140114/dbdb2b97/attachment.html>

Sorry for the very late response.
This is quite an interesting work, thanks for sharing!
I'm particularly interested in your [test suite][1] which is impressive.

This is making me realize that generators are fully compilable 
(efficiently from what I can see) into ES5 and makes me wonder if the 
current generators specificities are worth it. Very specifically, do we 
really need `Generator.prototype [ @@toStringTag ] === "Generator"` ?
 From an author point of view, I don't really see in which situation 
this information could matter. As a comparison, functions generated 
after the class syntax do not have an `@@toStringTag` to `"Class"`.
Generators would just be sugar to write iterators (+ .throw)


Le 03/11/2013 21:55, Ben Newman a écrit :

>   * Given that this tool will become obsolete as more and more engines
>     implement ES6 generator functions, how can we maximize its value
>     in the meantime? Are there grey areas in the draft spec that can
>     be illuminated? Should I spend my time implementing (or getting
>     others to implement) await syntax and/or control-flow libraries
>     that leverage generator syntax?
>

You can most certainly experiment with await syntax and share what 
you've learned.
Are there any test cases that you've written and you feel like the 
expected spec behavior is odd or unintuitive in some aspect?

>   * How would you design a system that selectively delivers transpiled
>     code to ES5-capable browsers and native generator code to
>     ES6-capable browsers, so that end users will benefit immediately
>     when they upgrade to a browser with native support for generators?
>

Since there is no semantic difference between the ES6 and your compiled 
version, it's unlikely the users will see a difference at all (not even 
sure the perf is that much different).

But if you really want to try there are different options with 
different  downsides.

1. Server-side UA sniffing. You get the User-Agent header, infer which browser it is and decide which version you should be sending. Send the  ES5 version when you don't know the UA (safe default)

  Downsides:

  * if a browser changes its header, you may be sending the wrong version. This is a problem when you're sending the ES6 version to a non-ES6 browser (which admittedly should be a very rare case)
  * You need to update the list of ES6 User-Agent strings as new browsers  arrive

2. Send a feature-detection JS snippet on the client which will decide  which version to load.

  Downside:

  * having to wait until this snippet is executed to start code download (or one extra round-trip if code was originally inlined)

3. send compiler to the client-side

  Downside:

  * more code

Personally, I'd go for sending the ES5 version to everyone. My second 
choice would be 1, but I guess it depends on the requirements.

[1]: https://github.com/facebook/regenerator/blob/master/test/tests.es6.js