220 5240 article Path: news.gmane.org!not-for-mail From: asaelr@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Some thoughts about coroutines Date: Wed, 26 Jun 2013 18:40:58 -0700 (PDT) Lines: 1405 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2129_3026738.1372297258221" X-Trace: ger.gmane.org 1372299384 26978 80.91.229.3 (27 Jun 2013 02:16:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Jun 2013 02:16:24 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCB23LHRZUKRB5OAV2HAKGQEFDXULCQ@isocpp.org Thu Jun 27 04:16:25 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yh0-f70.google.com ([209.85.213.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Us1l1-00053T-Gv for gclcip-std-proposals@m.gmane.org; Thu, 27 Jun 2013 04:16:24 +0200 Original-Received: by mail-yh0-f70.google.com with SMTP id l109sf332485yhq.9 for ; Wed, 26 Jun 2013 19:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:date:from:to:message-id:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-google-group-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=VSGpw4PdO6xbMcFjfwsgngNlmoO/YXxngLgHdhBknkQ=; b=p3zqDWdzUuREild+J9uRNRN/m2g+2ZSk1HCu+Z4GgPgcb5ixULeqDsKshyL8U1VQuy 2vhOcmTU336jTfwxo73XBLTo/7JsrxMrzCS8mtfAeWNJc0Fp0ztEsnQjzjt1Q6xwzjOP uydRNkTR34u44FUY3DefyNXGE5ydBvKuXreBTq1eCpd01JsTALrF0Ysw+4oSjFWrZGWc hRtWyVd8kALwGvl8xRikfmPMrO0SkX+6Q3Rlu154bz30Q8NVD2dNZlnV5StRelTx6nOC EmVxg3d87LNW/tgxm6HEEYHsKZqlpPBa8nQJ9fMm2aLp9qYJQ0YsQNvE7wG5dAP6vbiC Pgtg== X-Received: by 10.236.54.8 with SMTP id h8mr3629748yhc.11.1372299382706; Wed, 26 Jun 2013 19:16:22 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.50.228 with SMTP id f4ls723422qeo.29.gmail; Wed, 26 Jun 2013 19:16:21 -0700 (PDT) X-Received: by 10.224.29.76 with SMTP id p12mr5714788qac.5.1372299381119; Wed, 26 Jun 2013 19:16:21 -0700 (PDT) Original-Received: by 10.224.181.75 with SMTP id bx11msqab; Wed, 26 Jun 2013 18:40:58 -0700 (PDT) X-Received: by 10.49.129.104 with SMTP id nv8mr177277qeb.27.1372297258722; Wed, 26 Jun 2013 18:40:58 -0700 (PDT) X-Original-Sender: asaelr@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:5240 Archived-At: ------=_Part_2129_3026738.1372297258221 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Recently, I=92ve thought a lot about coroutines, and how they should behave= =20 if became a part of c++. I found two (main) proposals: a.=20 https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/3g6ZIWed= GJ8 It has the advantage of not requiring to change the syntax, but in force a= =20 new model of stack-based calls. It does so in purpose to let nested=20 functions to yield value, which I think is not really necessary. (If we let= =20 nested functions return value on behalf of their callee, we should start=20 this in regular functions). Also, Its syntax is somehow complex. b.=20 https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/PPZJVTDd= DVQ It is easy to use and doesn=92t require a new stack, and I think that this = is=20 the right direction. However, it ignores some technical details (lifetime= =20 of locals, etc). Also, adding a keyword may break too many working code,=20 and my personal opinion is that it is ugly. Sentences like =93void numbers(= )=20 yields int=94 reminds me too many things I hate in Java. The alternative=20 syntax (described at the end of this proposal) is not so ugly, but still=20 complex. There is even a nice implementation of coroutines (using macros):=20 http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html but it has 2 major disadvantages: while using it, we can=92t yield a value= =20 from within a switch statement, and, much more important, we have to define= =20 all the local variables at the top of the function - back to C90 days! (and= =20 with constructors this is much worst.) Another thing that was very little talk about, is for-range loops native=20 support. Let=92s say we have a Fibonacci number generator (a very common=20 example): (Using Denis Bredelet=92s proposal syntax) void fib(int n) yields int { int a=3D0,b=3D1; while(n--) { int c=3Da+b; a=3Db; b=3Dc; yield c; } } We want the possibility to write for (int i : fib(10)) std::cout<p0 && posp1 && posp2 && posp0 && posp1 && posp2 && posp2 && posp1 && posp0 && posRecently, I=92ve thought a lot about coro= utines, and how they should behave if became a part of c++.

I found two (main) proposals:

a. https://groups.google.com/a/isocpp.org/forum/#!topic/std-propos= als/3g6ZIWedGJ8

It has the advantage of not requiring to change the syntax, but in force a new model of stack-based calls. It does so in purpose to let nested=20 functions to yield value, which I think is not really necessary. (If we=20 let nested functions return value on behalf of their callee, we should=20 start this in regular functions). Also, Its syntax is somehow complex.

b. https://groups.google.com/a/isocpp.org/forum/#!topic/std-propos= als/PPZJVTDdDVQ

It is easy to use and doesn=92t require a new stack, and I think that this=20 is the right direction. However, it ignores some technical details=20 (lifetime of locals, etc). Also, adding a keyword may break too many=20 working code, and my personal opinion is that it is ugly. Sentences like =93void numbers() yields int=94 reminds me too many things I hate in Java.= =20 The alternative syntax (described at the end of this proposal) is not so ugly, but still complex.

There is even a nice implementation of coroutines (using macros): http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

but it has 2 major disadvantages: while using it, we can=92t yield a value=20 from within a switch statement, and, much more important, we have to=20 define all the local variables at the top of the function - back to C90=20 days! (and with constructors this is much worst.)


Another thing that was very little talk about, is for-range loops native=20 support. Let=92s say we have a Fibonacci number generator (a very common=20 example):

(Using De= nis Bredelet=92s proposal syntax)

void fib(int n) yields int {

 int a=3D0,b=3D1;

 while(n--) {

   int c=3Da+b;

   a=3Db;

   b= =3Dc;

  =  yield c;

&nb= sp;}

}

<= span style=3D"font-size:15px;font-family:Arial;color:#000000;background-col= or:transparent;font-weight:normal;font-style:normal;font-variant:normal;tex= t-decoration:none;vertical-align:baseline;">We want the possibility to writ= e for (int i : fib(10))= std::cout<<i<<=92\n=92; to print the first 10 Fibonacci numbers.


So what am I suggest?

First, to the syntax. Since we want it to work natively with for-range loops,=20 and since the  language concept is =93declare it the way you will use = it=94, I would suggest using colon in the function signature. The nicest idea I managed to think so far is int : fib(int n)

Also, there is no reason to add the keyword yield, when we can stick to good old return.<= /span>

Now, to the real st= uff: What does fib(10)<= /span> mean? What=92s the type= of fib(10).begin()?

I suggest this meaning: fib will be (auto-generated) class, and an object of it will represent calling the =93function=94 with specific parameters.= =20 The member function beg= in (and end) will return some sort of iterator, which will represent = the actual call.

So= me details: the fib class should have some mem= bers, to contain the parameters it called with, but the real fun is in the = iterator class: it will have (in addition to the parameters),  as (not exactly= , I will explain below) members, all the local variables of the =93function=94= =20 (including the return value), and also the information about where it=20 stopped last time (and should resume from) - let=92s call it, from now on, =93position data=94.

To be more precise: an iterator should contain the memory for the local variables (like every member=20 variable), but their lifetime will be as if they were local variables of the =93function=94. I mean - they will been constructed only when the=20 =93function=94 will decide so, and not automatically when the iterator is been constructed.

When the =93function=94 ends (either by falling = through the ending brace, not catching exception, or simply saying <= span style=3D"font-size:15px;font-family:Arial;color:#000000;background-col= or:transparent;font-weight:normal;font-style:italic;font-variant:normal;tex= t-decoration:none;vertical-align:baseline;">return; without a value), the position data should contain this information,=20 and (like every function), every local variable should be destructed.

Knowing the position data let us easily determine which variables are alive,=20 and so I think that the following member functions can be automatically=20 created:

copy const= ructor - should copy the position data, the parameters, and every living lo= cal variable

move c= onstructor - the same, but move instead of copy

destructor - destroy the parameters, and every= living local variable.

(Of course, if some local variable is noncopyable, so is the iterator)=

I think that it sh= ould not be assignable - If one iterator have a live object, and another on= e have not, it=92s a real mess.


Some e= xample:

Suppose that we want to yield the number 0, and then, the first n Fibonacci=20 numbers and the first n even number, alternately. To add more interest=20 (and to demonstrate more rules), I want to create and destroy some=20 objects (assume A is a copyable, moveable, and= int-constructive class), so I=92ve written the following code:

<= p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;">= int : fib_even(int n) {=

   A a(7)= ;

  &nbs= p;int fib1=3D0,fib2=3D1,even=3D0;

   return 0;

   while(n--) {

      &nb= sp;int fib3=3Dfib1+fib2;

       fib1=3Dfib2;

      &nb= sp;fib2=3Dfib3;

&n= bsp;      return fib3;

       A b=3Dn;=

   = ;    return even+=3D2;

   }

}


A compiler may = expand it to something like:

(Note: I=92m using dynamic memory allocation, but It=92s not really how it should= =20 be implemented - I just don=92t want some constructors and destructors to= =20 been invoked automatically)


class fib_= even {

  = ; class iterator {

       int n;

       int *f= ib1,*fib2,*fib3,*even;

       A *a,*b;

       int= *ret_value;

 = ;      enum {p0,p1,p2,p3,p4} pos; //resuming point= s

  =      void next() {

          &nbs= p;switch (pos) {

&= nbsp;              c= ase p0: break;

&nb= sp;              cas= e p1: goto label1;

=                = ;case p2: goto label2;

              &= nbsp;case p3: goto label3;

            &nbs= p;  case p4: return;

           }

//construct automatic variab= les of the function
=

   = ;        a=3Dnew A(7);

       &nb= sp;   fib1=3Dnew int(0);

           fi= b2=3Dnew int(1);

&= nbsp;          even=3Dnew int(0);

//the return process - create the value, save the resuming point, and return
<= /p>

    &= nbsp;      ret_value=3Dnew int(0);

       &= nbsp;   pos=3Dp1;

           return;

   &= nbsp;   label1:

           while(n= --) {

  =              fib3=3Dnew i= nt(*fib1+*fib2); //being constructed only now

        =        *fib1=3D*fib2;

        &nb= sp;      *fib2=3D*fib3;

         = ;      ret_value=3Dnew int(*fib3);

       &= nbsp;       pos=3Dp2;

        &nb= sp;      return;

       label2:

<= p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;">=      = ;          b=3Dnew A(n);

      &n= bsp;        ret_value=3Dnew int((*even)+=3D2)= ;

  &nbs= p;            pos=3Dp3;=

    =            return;

      &nb= sp;label3:

//automa= tic variables going out of scope, and should b= e destructed

&= nbsp;              d= elete b;

 &nb= sp;             delete fi= b3;

  &n= bsp;        }

         = ;  delete even;

           delete fib2;

   &nb= sp;       delete fib1;

        &n= bsp;  delete a;

           pos=3Dp4;=

    =    }

&nb= sp;      iterator(int n) : n(n),pos(p0) {

    &n= bsp;      next(); //get the first value

       }

      =  iterator() : pos(p4) {}

   public:

       iterator &oper= ator++() {

 &= nbsp;         delete ret_value;

    &n= bsp;      next();

           = ;return *this;

&nb= sp;      }

       int &operator*()= {

  &nb= sp;        return *ret_value;

      &n= bsp;}

  =      iterator(const iterator &it) : n(it.n),pos(it.= pos) {

//copy only = living members

=            if (pos>p0 &= ;& pos<p4) {

              &nbs= p;ret_value=3Dnew int(*it.ret_value);

           = ;    a=3Dnew A(*it.a);

           = ;    fib1=3Dnew int(*it.fib1);

        &nbs= p;      fib2=3Dnew int(*it.fib2);

       &n= bsp;       even=3Dnew int(*it.even);

      =      }

           if (pos>= ;p1 && pos<p4) fib3=3Dnew int(*it.fib3);

       &nb= sp;   if (pos>p2 && pos<p4) b=3Dnew A(*it.b);

    = ;   }

&n= bsp;      iterator(iterator &&it) : n(std:= :move(it.n)),pos(it.pos) {

           if (pos>= ;p0 && pos<p4) {

            &nb= sp;  ret_value=3Dnew int(std::move(*it.ret_value));

      &nb= sp;        a=3Dnew A(std::move(*it.a));

    = ;           fib1=3Dnew int(std::mov= e(*it.fib1));

&nbs= p;              fib2= =3Dnew int(std::move(*it.fib2));

           &nbs= p;   even=3Dnew int(std::move(*it.even));

       &nb= sp;   }

=            if (pos>p1 &= & pos<p4) fib3=3Dnew int(std::move(*it.fib3));

       &n= bsp;   if (pos>p2 && pos<p4) b=3Dnew A(std::move(*i= t.b));

  = ;     }

       ~iterator() {

      &= nbsp;    if (pos>p2 && pos<p4) delete b;

    = ;       if (pos>p1 && pos<p4) delete= fib3;

  = ;         if (pos>p0 && pos&l= t;p4) {

 &nbs= p;             delete eve= n;

  &nb= sp;            delete fib2;

   &n= bsp;           delete fib1;<= /p>

    &= nbsp;          delete a;

      &n= bsp;        delete ret_value;

      &n= bsp;    }

       }

       bool opera= tor!=3D(const iterator &it) {

           ret= urn pos!=3Dit.pos;

=        }

       operator bool() = {

  &nbs= p;        return pos<p4; //still hasn't ended

      &n= bsp;}

  =      iterator &operator=3D(const iterator&) =3D= delete;

 &nb= sp;     friend fib_even;

   };

   int n;

public:

   fib_even(int n) : n(n) {}

   iter= ator begin() {

&nb= sp;      return iterator(n);

   }

   iterator end() {

   &n= bsp;   return iterator();

   }

};


So, what do you = think?

--
 
---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
 
 
------=_Part_2129_3026738.1372297258221-- .