<div dir="ltr"><div><div>My experience implementing Regenerator is consistent with the nuance that Brendan is highlighting here, as I understand it.<br><br>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.<br>

<br></div>Now, I happen to think it's not that hard to keep those gaps from interfering with actual coding. The fact that <a href="https://github.com/facebook/regenerator/blob/master/test/tests.es6.js">https://github.com/facebook/regenerator/blob/master/test/tests.es6.js</a> passes 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.<br>

<br></div>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.<br>

</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div>Ben<br></div><br>His errors are volitional and are the portals of discovery.<br>-- James Joyce</div></div>
<br><br><div class="gmail_quote">On Sat, Jan 25, 2014 at 12:30 AM, Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.com" target="_blank">brendan@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">David Bruant wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Ben,<br>
<br>
Sorry for the very late response.<br>
This is quite an interesting work, thanks for sharing!<br>
I'm particularly interested in your test suite [1] which is impressive.<br>
<br>
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" ?<br>


>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".<br>
Generators would just be sugar to write iterators (+ .throw)<br>
</blockquote>
<br></div>
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.<br>


<br>
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.<span class="HOEnZb"><font color="#888888"><br>


<br>
/be<br>
</font></span></blockquote></div><br></div>