So I talked a bit to Mikeal about his concerns and there is a slight
misunderstanding here. The best I can tell, his concern is that people
will get used to using function* and yield with non-async code and then not
notice when they are used in async code. In other words, he's worried
programmers won't be aware that yield can suspend you and shared mutable
state can change while you're suspended.
Consider this terribly written program:
var sum, i;
function* reduce(arr) {
sum = 0;
for (i = 0; i < arr.length; i++) {
sum += arr[i];
yield sum;
}
}
What happens if I have two concurrent reduce instances running at once?
They will clobber eachother's shared sum and i variables.
His fear is people will write terrible code like this and test it locally
where there are no concurrent users. Then when they push to production and
suddenly there are concurrent requests on the system, crazy bugs arise.
The last thing we want is code that only breaks in production.
My question to people on the list is how is this any different than the
same hazard with normal function?
var sum, i;
function reduce(arr) {
sum = 0;
i = 0;
return function () {
if (i < arr.length) {
sum += arr[i++];
return sum;
}
};
}
There is no I/O, no generators, and nothing other than some closures and
some sync functions, yet it has the exact same hazards. It will work if
you never have more than one instance of reduce running at once and will
break when there are more.
On Tue, Aug 6, 2013 at 4:19 PM, Bruno Jouhier <bjouh...@gmail.com> wrote:
> 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 <mikeal...@gmail.com>wrote:
>>
>>>
>>> On Aug 5, 2013, at 4:16PM, Jake Verbaten <ray...@gmail.com> 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<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 nod...@googlegroups.com
>>>
>>> To unsubscribe from this group, send email to
>>> nodejs+un...@**googlegroups.com
>>>
>>> For more options, visit this group at
>>> http://groups.google.com/**group/nodejs?hl=en?hl=en<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 nodejs+un...@**googlegroups.com.
>>>
>>> For more options, visit
>>> https://groups.google.com/**groups/opt_out<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 nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> 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 nodejs+unsubscr...@googlegroups.com.
> 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 nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
