That's the problem, the assumption with a shallow yield is that the syntax flows all the way to the top of the stack so it can't abstract this away. You will always *see* a yield in your code, just like you *see* a callback now.
But if I write this generator in my library and offer it to you to consume and you let the event system turn in between yields my code is potentially unsafe, and operating in a condition I had not anticipated where more state can mutate than I thought, and it is going to have side effects. Removing assumptions is just as dangerous *down* the stack as it is *up* the stack. This strategy doesn't give the library author a lot of assurances about when the state can mutate even if it is clear to the library consumer. If we keep abstracting away the visible lines of safety and state change we're going to be back to the threaded programming whack-a-mole games of finding bugs in side effects at scale. Remember that we do not have the tools to manage safety people have built in other languages because we've been pretty explicit about when it can and cannot change and avoided a lot of problems which I see this train of thought re-introducing. -Mikeal On Aug 5, 2013, at 2:03PM, Andrew Gaspar <[email protected]> wrote: > I don't see why this would be an issue. Presumably if you're using something > like Q.async or galaxy or whatever, you implicitly understand that anything > following a yield could possibly/likely be occurring in a later turn of the > eventloop. > > Andrew Gaspar > > > On Mon, Aug 5, 2013 at 1:53 PM, Mikeal Rogers <[email protected]> wrote: > > On Aug 5, 2013, at 1:51PM, Tim Caswell <[email protected]> wrote: > >> It doesn't >> >> >> On Mon, Aug 5, 2013 at 1:32 PM, Mikeal Rogers <[email protected]> >> wrote: >> I don't see how generators are going to change how actual async programming >> happens in node.js, at least in ES6. >> >> It doesn't change how things work internally. Libraries and node core >> should only use callbacks. That's the lingua franca between all the >> competing async programming styles and libraries. >> >> >> Generators in ES6 are "shallow," they cannot yield until some time in the >> future when IO is done. Generators could be combined with some kind of >> promise interface, along with a new keyword, to yield a promise that spans >> turns of the event system, but this is ES7+ theoretical stuff we're talking >> about now. >> >> The biggest way generators affect control-flow libraries and what they can >> add on top as sugar is you can easily make a library (like galaxy, suspend, >> co, or my own gen-run) that consumes continuables or user-space promises and >> suspends the generator, resuming it when the promise/continuable resolves. > > If you abstract away the turn of the eventloop how does the programmer know > when they have a lock on local state mutations and when they don't? > >> >> But today, I would only do this in application level code and never in >> libraries or node core. >> >> A great example of this separation is how I use generators in js-git. The >> library is entirely callback based. I make all my external facing API >> functions work in dual mode as node-callback-last or return-continuable >> style with a single line at the top: >> >> function readFile(path, callback) { >> if (!callback) return readFile.bind(this, path); >> ... >> } >> >> And in my examples and documentation, I show how to consume the library >> using either traditional callback style of the new generator style using >> gen-run. >> >> See https://github.com/creationix/js-git/blob/master/examples/read.js vs >> https://github.com/creationix/js-git/blob/master/examples/read-generator.js >> >> Once generators land in a stable release of node.js and not behind a v8 flag >> *and* in all browser clients my library runs in, then I may change my policy >> about never depending on them in libraries. But I'll gladly use generators >> in my documentation since it makes things much easier to read and has a lot >> less boilerplate noise. >> >> >> The biggest thing I see generators effecting in the short term is stuff like >> underscore/lodash because it presents an alternative and, arguably, more >> efficient way to process iterators which is most of what people do with >> those libraries. If successful the impact would not be small as underscore >> is currently the most depended on library in npm, more than async, which >> means this could actually effect more people than some future promise thing >> or alternative to callbacks. >> >> -Mikeal >> >> On Aug 5, 2013, at 11:20AM, Andrew Gaspar <[email protected]> >> wrote: >> >>> This is a discussion that has been had time and time again, and it seems >>> the general consensus is this - callbacks are about as low level as they >>> can go to achieve asynchrony and if you want to wrap that in a different >>> construct that you find more useful, then that is something you can either >>> use a third party module for or do yourself. >>> >>> I also greatly prefer promises over callbacks because they are so much >>> easier to reason about and compose, but I understand that is not >>> everybody's favorite abstraction, and can be unnecessary in some >>> circumstances, so I think the right decision was made in not including it >>> in the standard API. >>> >>> Andrew Gaspar >>> >>> >>> On Mon, Aug 5, 2013 at 8:23 AM, Christopher Probst >>> <[email protected]> wrote: >>> Hi guys, >>> >>> today I read something about the upcomming es6 generator support and how >>> useful they are in combination with promises (Q library for instance). >>> >>> The problem with node is that it provides only asynchronous functions (and >>> synchronous.. pff). >>> I think in order to use promised based io the node.js should support an >>> additional function for each asynchronous function in the future or maybe a >>> library which does this. >>> >>> I know that the Q library already exports functions like "Q.denodeify" so >>> it's definitely not much work but it's still work. >>> >>> I've started with node a year ago and it is really a nice tool but I always >>> hated the callbacks. They are not composable, verbose and absolutely ugly. >>> >>> What do you think about this issue ? Any chance direct support for this >>> will ever be added ? >>> >>> Regards, >>> Chris >>> >>> -- >>> -- >>> Job Board: http://jobs.nodejs.org/ >>> Posting guidelines: >>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >>> You received this message because you are subscribed to the Google >>> Groups "nodejs" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/nodejs?hl=en?hl=en >>> >>> --- >>> You received this message because you are subscribed to the Google Groups >>> "nodejs" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >>> >>> -- >>> -- >>> Job Board: http://jobs.nodejs.org/ >>> Posting guidelines: >>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >>> You received this message because you are subscribed to the Google >>> Groups "nodejs" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/nodejs?hl=en?hl=en >>> >>> --- >>> You received this message because you are subscribed to the Google Groups >>> "nodejs" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >> >> >> -- >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "nodejs" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> >> >> -- >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "nodejs" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> > > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
