Catching up a bit late. As Marcel explained, there is no risk of yield interrupting a normal run-to-completion flow: yield is only allowed into function* so you get a compile error if you try to yield inside a normal function.
Then there is no need for any special naming conventions: asynchronous functions are "starred" (function*) while normal (run-to-completion) functions are "unstarred". Special async/await syntax is not strictly necessary either. If you look at galaxy, you'll see that async/await can be achieved with function*/yield and without any annoying library calls in the way: async code becomes function* yielding on function* calls yielding on function* calls, ..., just like async function awaiting on async function calls awaiting on async function calls .... A true await keyword would only help with the annoying precedence of yield. I find the concurrency strawman (http://wiki.ecmascript.org/doku.php?id=strawman:concurrency) much more elegant than the await syntax (which does not chain well before of prefix operator). Last, a few words on "state mutations". Mikeal keeps making a huge fuss about them but in typical "application" code: 1) most of the code manipulates state which is associated with the "current request". If the code is reasonably written it is easy to guarantee that code executing in the context of request A does not interfere with state associated to request B. 2) if serveral operations P, Q, R, .... are run in parallel to fulfill request A a reasonable design is to have P, Q, R, ... manipulate their own private contexts which are disjoint from each other. Then A will deal with the results producted by P, Q and R, not with the private contexts of the operations while they run in parallel. This is a very natural way of parallelizing execution with futures. 3) shared immutable state is no problem 4) Then we have the problematic part: mutable state which is shared by concurrent requests. In a well written application, there should not be too many places like this, mostly global registration modules, global caches, etc. And, yield makes it very easy to verify if this code is correct: any block of code which does not contain any yield just runs to completion (and you don't have to look into the functions that are being called). And sometimes you need a critical section around some async calls: this is where I use the little funnel utility that I created for streamline. So, shared mutable state is not everywhere. In a well written application, it is encapsulated behind simple robust module APIs and the rest of the code does not care about it. This is also why classical EH (try/catch/finally) can be used in applicative code: when you unwind the stack you discard mutations that have been done on state that is private to your request or your operation, not mutations on shared state. In short, shared mutable state can be contained. Bruno On Tuesday, August 6, 2013 1:47:17 AM UTC+2, Mark Hahn wrote: > > Mikeal, it seems this could be solved by a naming convention. Any library > call that uses generators could start with async, like asyncDoit, or more > reasonably, some convention like ending with a dollar sign: doIt$. > > On Mon, Aug 5, 2013 at 4:26 PM, Mikeal Rogers > <[email protected]<javascript:> > > wrote: > >> >> On Aug 5, 2013, at 4:16PM, Jake Verbaten <[email protected] <javascript:>> >> wrote: >> >> The only confusion is knowing whether your using generators for async >> flow control or whether your using them to generate iterators you iterate >> over. >> Once you learn to only use the first type in synchronous fashion and >> only use the second type in an asynchronous fashion the confusion goes away. >> >> >> This is *exactly* what I'm worried about. >> >> I'm trying to think about this not in the context of "all the code I >> write" but "all the code i use, and what they use, and what they use". >> >> If yield becomes a successful pattern a library user won't be aware of >> all the dependent generators it has, just like very few people are aware of >> their dependencies dependencies dependencies. Yet somehow all of the actors >> along this chain have to be sure they didn't use generators one way when I >> want to use them another way. >> >> This is very concerning. Patterns should enforce or at the very least >> visibly display the compatibility they offer so that actors can coordinate >> without active collaboration, this sounds like it depends on a bunch of >> people all agreeing about how their API should be used without any visible >> indicator stating such. >> >> One of two things will happen: >> >> * Most iterators will be used for async which means that very few people >> will write them in a way that i'm worry about >> OR >> * Most iterators won't be use for async which means mixing up the two >> cases will end in bugs *only* visible at scale. >> >> -Mikeal >> >> -- >> -- >> 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]<javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> 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] <javascript:>. >> 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.
