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 <[email protected]> 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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
