Boost logo

Boost :

Subject: Re: [boost] [Review.Coroutine] More comments, questions and suggestions
From: Eugene Yakubovich (eyakubovich_at_[hidden])
Date: 2012-09-10 18:54:28


>>> What about forcing the coroutine function return void, as it is the case
>>> now for the generator?
>>>
>>> voidfn( coro_t::self_t & self, int i)
>>> {
>>> self.bind(i);
>>> std::cout << "fn(): local variable i ==" << i << std::endl;
>>>
>>> self.yield(i);
>>> std::cout << "fn(): local variable i ==" << i<< std::endl;
>>> self.yield(i);
>>>
>>> }
>>>
>>> This should help to simplify user code, isn't it?
>>
>> I would not force the user to use self_t::yield() a simple return
>> statement does the same.
>
> The current interface forces the user to return the last value using
> 'return', which seems no better to me. Or, would this perform better?
>
> BTW, I understand that the following coroutine returns twice, but it is a
> little bit obscure, as there are two ways to return a value from a
> coroutine.
>
> int f( coro_ref::self_t & self, int a)
> {
> return self.yield( a);
> }
>
> LUA follows the same schema, but I don't share it. I you adopt the same
> design as generators there will be no possible confusion. Only one way to
> yield a value.
>
> What do others think?

That's an interesting idea. If you couple it with the argument I made
few mins ago regarding not invoking generator-function in generator's
constructor, the coroutines and generators start to look very similar.
The only difference would basically be that generators don't have
arguments (yield returns void). But then maybe we can learn something
from Python here. They also started with pure generators (sending
values one way) but eventually extended them to be bidirectional.
Maybe we can unite coroutine and generator into just one class?

Regards,
Eugene


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk