220 22002 article Path: news.gmane.org!not-for-mail From: Giovanni Piero Deretta Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: is await an extension of the do-notation? (was Re: Re: Resumable expressions p0114r0 vs async/await P0057R0) Date: Tue, 27 Oct 2015 01:24:45 -0700 (PDT) Lines: 181 Approved: news@gmane.org Message-ID: References: <639f0012-8cb4-4db3-82a6-8d042a3497f9@isocpp.org> <401aa118-ed0b-4c7b-92cf-3fbd706eff9d@isocpp.org> <1d15dbc4-e0c1-4df1-86db-014e11f14d26@isocpp.org> <56114953.4030701@wanadoo.fr> <561B403D.4030403@gmail.com> <561C07D1.3080304@gmail.com> <561C213F.1060009@gmail.com> <561C3875.2050701@gmail.com> <86924069-44d0-447f-bf8a-a42e46579832@isocpp.org> <561D79A7.8080007@gmail.com> <894616d6-9609-4038-b2bc-d2c62df21e0f@isocpp.org> <99bdb3ae-9214-4440-8572-4c47a61eda46@isocpp.org> <58628096-14ae-42b2-89d3-c0bd2183bbc0@isocpp.org> <561DC957.8080603@gmail.com> <2e09660f-d688-474a-8811-85fb041f68b8@isocpp.org> <8b78abb4-16b6-4b65-8513-6e2c17317647@isocpp.org> <779be861-3b2a-427a-b36b-ad2874c81129@isocpp.org> <767364f8-785d-4f8f-9bc0-852df56ee4eb@isocpp.org> <0a728eee-e8e7-48ea-adf6-2a8dae63916e@isocpp.org> <6a4f863e-faf0-42ac-b85d-0951738350ab@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_71_194596750.1445934286048" X-Trace: ger.gmane.org 1445934312 13726 80.91.229.3 (27 Oct 2015 08:25:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 Oct 2015 08:25:12 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDEP3I7TGEIM72N4WECRUBDLRLRSW@isocpp.org Tue Oct 27 09:24:56 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZqzYs-0000kT-IH for gclcip-std-proposals@m.gmane.org; Tue, 27 Oct 2015 09:24:54 +0100 Original-Received: by vkgy127 with SMTP id y127sf308121729vkg.2 for ; Tue, 27 Oct 2015 01:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=j4bpM9bhQvjKnMSD/osgsLxzS/Ti+arhdOBhF9Kh6IM=; b=CEqq2g0pHeGTKkF41U9dGkO+eWiLHp4J7/hq5Mbc250adxOEkf/y3Wo0+Q5y1MIjZZ nFwyIE/GChk3lvtEl/cRMzVXT/NVl0u9hQt4XHslSRxTx3aNfmfi4pVEneT7PkYgXQiH OBEibdHkUzdmSJ4WaQzANz3xHlq7zrYdCv4BBQ+5HZ5c3gXVA2OFrKdVJjFAYHGMr5H5 QTRd7XNo2AI+Vkw9TfP38RnoOdBqIPLnG0SWdCJFCfZGtULdBU1YXpMfy63RubxyWkoU 87V0S0lhTfXd9v/c+mT8Ea01VIM3XBMCp3bZnkBos/T2xeTxYVRwF7HnuZGo691Tfmtk S/5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=j4bpM9bhQvjKnMSD/osgsLxzS/Ti+arhdOBhF9Kh6IM=; b=QJTEC7CwhN8AxeEit8H2nujmlSaQZ1OO+Nx5QXl2BHj6pBAj7QIlU82jxIIzprMOww CuIkcjeyaeTsRN0AR5WZ45Z5lYpzsxgAA0eDchaBlZ1g7mO1SARtJgeoZR5/uXL0ohyx MS6RuFXO2rWPNvm+2dlZ6vc9RIfiCUieXE//C/LTEcNCbvlxuXPyl+swrq+3rZ7ukLdz 3oVVe//sTgj319BzL6wo/nhTZzhulThxdNNFfkEOD1h2JMkKM+4Gv+47/iasFUjGS+Mg +n7ZvuD4Z3zBahP/mJg2Ycixu5eR/DBXEktbmtBCEFFrNS/Q0S6XYhkAaJd5AntJfzrJ nR5w== X-Gm-Message-State: ALoCoQlhne8DrZzRGSrxr02jCpHNi4c/MIncCP8muOiMrZ3GfzWpvhWBzEAHVVD10rTiPPbXr6iR X-Received: by 10.31.171.12 with SMTP id u12mr33452333vke.12.1445934288359; Tue, 27 Oct 2015 01:24:48 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.132.83 with SMTP id g80ls2177754iod.32.gmail; Tue, 27 Oct 2015 01:24:47 -0700 (PDT) X-Received: by 10.50.32.37 with SMTP id f5mr80101igi.10.1445934287487; Tue, 27 Oct 2015 01:24:47 -0700 (PDT) In-Reply-To: X-Original-Sender: gpderetta@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:22002 Archived-At: ------=_Part_71_194596750.1445934286048 Content-Type: multipart/alternative; boundary="----=_Part_72_1627382834.1445934286049" ------=_Part_72_1627382834.1445934286049 Content-Type: text/plain; charset=UTF-8 On Tuesday, October 27, 2015 at 6:48:02 AM UTC, Oliver Kowalke wrote: > > 2015-10-22 14:47 GMT+02:00 Giovanni Piero Deretta >: > >> template >> class context; >> >> template >> context::context() ; // create any empty context >> >> template >> context::context( Fn && fn, Args && ... args); // requires >> IsSame, args..), context>; >> >> template >> R context::operator()(T); // invokes context and implicitly pass to it >> this context. On return 'this' contains the context we are coming from. >> Returning it explicitly is an alternative. >> > > I believe that this API might only work for asymmetric context switching: > > void bar( context synthctx2) { > synthctx(); > } > > void foo( context synthctx1) { > context ctx2( bar); > ctx2(); > } > > context ctx1( foo); > ctx1(); > > context 'ctx1' and 'ctx2' own a side-stack > 'synthctx1' and 'synthctx2' are synthesized context' (ctor of 'ctx1' and > 'ctx2') passed as argument to 'foo() / 'bar()' > 'synthctx1' is used to switch back to 'foo' (re-enter context ctx1), but > it does not own (or has a connection to) the side stack > managed by 'ctx1'! > in the ctor of 'ctx2' we have not access to the control structure managing > the side-stack of 'ctx1' > 'synthctx1' is not equivalent to 'ctx1' but of the same type - that > foolish the user > > why would ctx2 need to access the control structure of ctx1? Note that I have implemented the api and works perfeclty fine for both async coroutines (i.e. generators) and synchronous (tasks, fibers) Anyway, in my model, the stack is not owned by a context. It is owned by the bottommost function frame. I neglected to mention a point in the previous discussions: when returning to the bottomost frame (directly or via an exception), a context must be passed. Because the api is completely symmetric and explicit, there are no implicit pointers anywhere, expclitily returning a context is needed so that the bottom stack frame know to which context to return to on termination. This is the full example: context bar( context other2) { other2(); return other2; } context foo( context other) { context bar_ctx( other ); bar_ctx(); return bar_ctx; } context foo_ctx( foo); ctx(); To handle exceptions, there is a need of a wrapper exception type that carries a context plus a nested exception. When the bottomost frame is reached, it switches to the context payload, delete the outgoing context stack and rethrows the exception. Also note that there is nothing synthetic about the 'other' contextes; they are contextes exactly like the others. > -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email 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/. ------=_Part_72_1627382834.1445934286049 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <= br>On Tuesday, October 27, 2015 at 6:48:02 AM UTC, Oliver Kowalke wrote:
2015-10-22 14:47 GMT+02:00 Giovanni Piero Deretta <gpde...@gmail.com>:
template<class T, class R>
class context= ;

template<class T, class R>
context::context() ; // create= any empty context

template<class T, class R>
context::cont= ext( Fn && fn, Args && ... args); // requires IsSame<res= ult_of<Fn(context<R,T>, args..), context>;

template= <class T, class R>
R context::operator()(T); // invokes context an= d implicitly pass to it this context. On return 'this' contains the= context we are coming from. Returning it explicitly is an alternative.
=

I believe that this API might only w= ork for asymmetric context switching:

void bar( context s= ynthctx2) {
=C2=A0=C2=A0 synthctx();
}

<= /div>
void foo( context synthctx1) {
=C2=A0=C2=A0 context= ctx2( bar);
=C2=A0=C2=A0 ctx2();
}

cont= ext ctx1( foo);
ctx1();

context= 'ctx1' and 'ctx2' own a side-stack
'synt= hctx1' and 'synthctx2' are synthesized context' (ctor of &#= 39;ctx1' and 'ctx2') passed as argument to 'foo() / 'ba= r()'
'synthctx1' is used to switch back to 'f= oo' (re-enter context ctx1), but it does not own (or has a connection t= o) the side stack
managed by 'ctx1'!
in= the ctor of 'ctx2' we have not access to the control structure man= aging the side-stack of 'ctx1'
'synthctx1' is not equiva= lent to 'ctx1' but of the same type - that foolish the user

=

why would ctx2 need to access the control= structure of ctx1? Note that I have implemented the api and works perfeclt= y fine for both async coroutines (i.e. generators) and synchronous (tasks, = fibers)
=C2=A0
Anyway, in my model, the stack is not owned by a conte= xt. It is owned by the=C2=A0 bottommost function frame. I neglected to ment= ion a point in the previous discussions: when returning to the bottomost fr= ame (directly or via an exception), a context must be passed. Because the a= pi is completely symmetric and explicit, there are no implicit pointers any= where, expclitily returning a context is needed so that the bottom stack fr= ame know to which context to return to on termination.=C2=A0 This is the fu= ll example:

context bar( context other2) {
=C2=A0= =C2=A0 other2();

=C2=A0=C2=A0 return other2;
}

=
context foo( context other) {
=C2=A0=C2=A0 context= bar_ctx( other );
=C2=A0=C2=A0 bar_ctx();

=C2=A0 retu= rn bar_ctx;
}

context foo_ctx( foo);
ctx();
To handle exceptions, there is a need of a wrapper exception type tha= t carries a context plus a nested exception. When the bottomost frame is re= ached, it switches to the context payload, delete the outgoing context stac= k and rethrows the exception.
Also note that there is nothing synthetic = about the 'other' contextes; they are contextes exactly like the ot= hers.

--

---
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-proposa= ls+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_72_1627382834.1445934286049-- ------=_Part_71_194596750.1445934286048-- .