220 21617 article Path: news.gmane.org!not-for-mail From: Richard Smith 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: Mon, 12 Oct 2015 12:53:38 -0700 Lines: 146 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11438a8e7859710521edaf7a X-Trace: ger.gmane.org 1444679625 4722 80.91.229.3 (12 Oct 2015 19:53:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Oct 2015 19:53:45 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDVNBJG4YAIBBQ476CYAKGQE2XC5MBY@isocpp.org Mon Oct 12 21:53:44 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f200.google.com ([209.85.223.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZljAE-0003fd-Qg for gclcip-std-proposals@m.gmane.org; Mon, 12 Oct 2015 21:53:43 +0200 Original-Received: by ioii196 with SMTP id i196sf305436962ioi.3 for ; Mon, 12 Oct 2015 12:53:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=DkJLiZUcIuun1pIda1QsM+l/pr+GpChGX54Hgi7U3Bw=; b=dEVut+ahVA/LwxWp8DR/ws0AAH1m9y3LJnBi/6BtiBQ4V5j8SZasUhGk3LlJMHiT8w lPRCfm9jGzVtdwopBzl2VvXVIe7eVM7UWGR6TJcvyIKpWNFa9nQC1JzUc/7l4YqN4abK LnvFjl9oENSo1ZHLDLjfojvmjCDpE3KD8o2Bc4VfliAGHdiPo5cyDGWmgzZlp6Ju3rU+ ydfjvs52npJeyYDvRnxUk6oRMl2PU4A8E6vg9FZQBLCbcC38FgmEeWu/5QZbnYH/R0gg MCXsm7LiXHPEpEycCAMyzbhtWZgc9iawz7GABz21zhNyd9hrVpneNVdtKzOp86Co+DrT iB6A== X-Gm-Message-State: ALoCoQknjYAJyvRWfBOd5VbPev+VSbpEk+dCX9u6/ldaR3fjTCE/zjelVOJsM3BwcBj+2nNBdRSl X-Received: by 10.182.52.132 with SMTP id t4mr25671290obo.16.1444679621254; Mon, 12 Oct 2015 12:53:41 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.95.108 with SMTP id h99ls3083877qge.77.gmail; Mon, 12 Oct 2015 12:53:38 -0700 (PDT) X-Received: by 10.31.157.131 with SMTP id g125mr5396660vke.24.1444679618933; Mon, 12 Oct 2015 12:53:38 -0700 (PDT) Original-Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com. [2607:f8b0:400c:c05::236]) by mx.google.com with ESMTPS id x67si5317117vkx.59.2015.10.12.12.53.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Oct 2015 12:53:38 -0700 (PDT) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c05::236 as permitted sender) client-ip=2607:f8b0:400c:c05::236; Original-Received: by vkaw128 with SMTP id w128so35612071vka.0 for ; Mon, 12 Oct 2015 12:53:38 -0700 (PDT) X-Received: by 10.31.162.81 with SMTP id l78mr19260210vke.13.1444679618416; Mon, 12 Oct 2015 12:53:38 -0700 (PDT) Original-Sender: metafoo@gmail.com Original-Received: by 10.31.142.72 with HTTP; Mon, 12 Oct 2015 12:53:38 -0700 (PDT) In-Reply-To: <561C07D1.3080304@gmail.com> X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c05::236 as permitted sender) smtp.mailfrom=metafoo@gmail.com; dkim=pass header.i=@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:21617 Archived-At: --001a11438a8e7859710521edaf7a Content-Type: text/plain; charset=UTF-8 On Mon, Oct 12, 2015 at 12:19 PM, Evgeny Panasyuk wrote: > 12.10.2015 21:46, Richard Smith: > >> If use same underlying technique as was used at macro-based >> stackless coroutines of Boost.Asio then it can work with list monad, >> because such coroutine is just value type which can be copied/moved. >> >> >> It doesn't really work; you can't support local variables with such a >> model, because their lifetimes could be reentered after they end. >> > > Local variables do work with technique used by stackless coroutines of > Boost.Asio (and proposals like N4244). > > With such approach coroutine is transformed into class. Local variables > are transformed into fields of class (more precisely into nested unions > corresponding to scopes, as described in N4244), and coroutine body is > transformed into method-state-machine, where it's states correspond to > yield points. > This already can be implemented via macros to some extent. > I think you've missed my point about object lifetime. Consider: list_monad f(list_monad ints) { { auto x = make_shared(42); auto &r = x; int y = await ints; // #1, suppose this behaves like a list monad cout << *r + y; } // #2 return 0; } No matter how you transform this into a class, it won't actually work (and rightly so): the lifetime of the x object ends the first time line #2 is reached. When you try to resume at line #1, there's no way to bring x back to life again. Now, you might suggest that the way to solve this is to make a copy of the monad state at the point where we hit the 'await', so you can "safely" resume it multiple times. But that doesn't work either: your copy's 'r' would refer to the original's 'x' (whose lifetime has ended), not to the copy's 'x'. Moreover, C#'s await is implemented based on similar approach: > http://www.codeproject.com/Articles/535635/Async-Await-and-the-Generated-StateMachine The implementation approach is fine for coroutines (C#'s await doesn't support the list monad / continuations), but doesn't work for the full generality of monads in a system with mutable state. -- --- 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/. --001a11438a8e7859710521edaf7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Oct 12, 2015 at 12:19 PM, Evgeny Panasyuk <evgeny.panasyuk@gma= il.com> wrote:
12.10.2015 21:46, Richard = Smith:
=C2=A0 =C2=A0 If use same underlying technique as was used at macro-based =C2=A0 =C2=A0 stackless coroutines of Boost.Asio then it can work with list= monad,
=C2=A0 =C2=A0 because such coroutine is just value type which can be copied= /moved.


It doesn't really work; you can't support local variables with such= a
model, because their lifetimes could be reentered after they end.

 Local variables do work with technique used by stackless coroutines of Boos= t.Asio (and proposals like N4244).

With such approach coroutine is transformed into class. Local variables are= transformed into fields of class (more precisely into nested unions corres= ponding to scopes, as described in N4244), and coroutine body is transforme= d into method-state-machine, where it's states correspond to yield poin= ts.
This already can be implemented via macros to some extent.
=

I think you've missed my point about object lifetim= e. Consider:

list_monad<int> f(list_monad<= ;int> ints) {
=C2=A0 {
=C2=A0 =C2=A0 auto x =3D = make_shared<int>(42);
=C2=A0 =C2=A0 auto &r =3D x;<= /div>
=C2=A0 =C2=A0 int y =3D await ints; // #1, suppose this behaves l= ike a list monad
=C2=A0 =C2=A0 cout << *r + y;
=C2=A0 } // #2
=C2=A0 return 0;
}

<= /div>
No matter how you transform this into a class, it won't actua= lly work (and rightly so): the lifetime of the x object ends the first time= line #2 is reached. When you try to resume at line #1, there's no way = to bring x back to life again. Now, you might suggest that the way to solve= this is to make a copy of the monad state at the point where we hit the &#= 39;await', so you can "safely" resume it multiple times. But = that doesn't work either: your copy's 'r' would refer to th= e original's 'x' (whose lifetime has ended), not to the copy= 9;s 'x'.

Moreover, C#'s await is implemented based on similar approach: http://www.codeproject= ..com/Articles/535635/Async-Await-and-the-Generated-StateMachine

The implementation approach is fine for coroutines= (C#'s await doesn't support the list monad / continuations), but d= oesn't work for the full generality of monads in a system with mutable = state.

--

---
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>.
--001a11438a8e7859710521edaf7a-- .