On Sun, Aug 1, 2010 at 5:13 PM, Greg Ewing greg.ewing@canterbury.ac.nz wrote:
ghazel@gmail.com wrote:
What I am suspicious of is automatically making calls to cofunctions from within a cofunction imply 'yield from'. Knowing whether the function call you are making can suspend your code and return to your parent or not is important,
The same situation occurs when dealing with threads, since any function you call could potentially suspend your thread. This doesn't seem to bother people much.
Exactly, it is the same situation as in threads, when it does not have to be. If you can be preempted at any point, suddenly there is a need for more fine-grained "locking" around state since you can not be sure that some function will not pause your execution and allow something further up the stack to modify it. With a special calling mechanism these cooperative points are very clear, and you can write code to handle potential state changes when the call returns. Instead of locking around state, cooperative points are like unlocking for the duration of the call.
I would like to see a different calling mechanism when calling a cofunction,
The main point of the whole thing is to avoid having to specially mark call sites like this. If you take that away, all that's left is the ability to define a generator without a yield, and I'm not sure it's worth having a whole new kind of function definition just for that.
Well, codef is the part I would like to see if anything is added at all. Maybe that's not worth the trouble.
-Greg