My experience implementing Regenerator is consistent with the nuance that
Brendan is highlighting here, as I understand it.

The state machines that Regenerator produces behave to the outside world
almost exactly as generators are supposed to behave, but there are gaps: as
an example, direct eval inside a generator would have access to
state-machine specific state (i.e. the $ctx variable), because some of the
machinery that V8 or SpiderMonkey are able to keep hidden simply has to
operate in the realm of end-user source code when you don't have native
support for generators.

Now, I happen to think it's not that hard to keep those gaps from
interfering with actual coding. The fact that
https://github.com/facebook/regenerator/blob/master/test/tests.es6.jspasses
without translation in Node v0.11.2+ is a testament to how close the
semantics are. But in order for a transformation to be considered
"desugaring," I agree with Brendan that there have to be no observable gaps
in semantics.

If you're building a library based on generators, I definitely recommend
writing your code in the most agnostic way you can—for instance, accept any
object that has a .next and .throw method as a generator, rather than
requiring it to be instanceof Generator, since that's not a built-in
constructor in ES5 environments.

Ben

His errors are volitional and are the portals of discovery.
-- James Joyce


On Sat, Jan 25, 2014 at 12:30 AM, Brendan Eich <brendan at mozilla.com> wrote:

> David Bruant wrote:
>
>> 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)
>>
>
> The answer is that class constructor is a Function instance, not a
> ClassFunction instance, because classes are mostly sugar for the prototypal
> pattern, whereas generators do *not* desugar in any
> translating-not-compiling sense.
>
> Matthias Felleisen wrote a paper, "On the Expressive Power of Programming
> Languages", that gets at the difference between compilation in general and
> translation or desugaring. You say generators are sugar to write iterators
> (+ .throw), but my understanding per Felleisen is that's an abuse of
> "sugar". Regenerator is a compiler, not a translator of
> like-to-like-expressiveness languages.
>
> /be
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140125/4c070e32/attachment.html>

My experience implementing Regenerator is consistent with the nuance that
Brendan is highlighting here, as I understand it.

The state machines that Regenerator produces behave to the outside world
almost exactly as generators are supposed to behave, but there are gaps: as
an example, direct eval inside a generator would have access to
state-machine specific state (i.e. the $ctx variable), because some of the
machinery that V8 or SpiderMonkey are able to keep hidden simply has to
operate in the realm of end-user source code when you don't have native
support for generators.

Now, I happen to think it's not that hard to keep those gaps from
interfering with actual coding. The fact that
https://github.com/facebook/regenerator/blob/master/test/tests.es6.jspasses
without translation in Node v0.11.2+ is a testament to how close the
semantics are. But in order for a transformation to be considered
"desugaring," I agree with Brendan that there have to be no observable gaps
in semantics.

If you're building a library based on generators, I definitely recommend
writing your code in the most agnostic way you can—for instance, accept any
object that has a .next and .throw method as a generator, rather than
requiring it to be instanceof Generator, since that's not a built-in
constructor in ES5 environments.