220 21796 <8a973164-304b-4ddc-85e7-fecc20b9c586@isocpp.org> article Path: news.gmane.org!not-for-mail From: Evgeny Panasyuk 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: Wed, 14 Oct 2015 14:46:34 -0700 (PDT) Lines: 299 Approved: news@gmane.org Message-ID: <8a973164-304b-4ddc-85e7-fecc20b9c586@isocpp.org> 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> <510ce172-976a-4e3a-ae68-31fdb40af4d7@isocpp.org> <9dd3f28c-4ffb-4e08-9955-242c46e14527@isocpp.org> <561DEFFD.2010802@gmail.com> <76d7c4dd-0ebc-4785-9559-34832ec5b884@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_13_761263283.1444859194339" X-Trace: ger.gmane.org 1444859200 31765 80.91.229.3 (14 Oct 2015 21:46:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 21:46:40 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC54TLGKR4LBBO427OYAKGQEAHBNJRQ@isocpp.org Wed Oct 14 23:46:40 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f198.google.com ([209.85.213.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZmTsb-0002Nt-CN for gclcip-std-proposals@m.gmane.org; Wed, 14 Oct 2015 23:46:37 +0200 Original-Received: by igcsm6 with SMTP id sm6sf3631168igc.2 for ; Wed, 14 Oct 2015 14:46:36 -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=iFgonVBASEJStUyI941/3zVnHVVlX0LKYubPA+bOD7o=; b=AvsZvoXCdxJyAAkIiDcxvxmcg0pmvVZQRghYB1VGrkfoZeP0Et6sIhtM2nvDOWo+B+ kGHZ7zH/lCgIWB3WR6CYP+w6l/DKUGIJp8VUnWiGP/XavWICD78w1gTCC8Qj5s6GyP8P HqK9tIK21JaRYvfTFnVm++bYcU32UZIQ2iCLKrvk6BztvlciJKow+HGKrrb3tfHFcRPU aaw1J6RXFMH7+E+zxvEjzyscNMYIU+aBXFncVUD8EvuSAY0FwyjpJFfuXO0m828dMVFG wJwIwS0MYNs6JCGxUB+/nEtsOhyR6wbwbrYv94H/ZOGwsoWElNILncJwb/LAqARTOzSO z1yg== 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=iFgonVBASEJStUyI941/3zVnHVVlX0LKYubPA+bOD7o=; b=NKkifDlc5RV4+NW1krokfqRWfOT7jHBo8RWpwdM8XHkxzZv1ixImJ0UI7Wq/KuK4Jc W8FisUkC6dwbRF3r30kEs2W5WQ5gvZ/Oy0naXyJhQmz6y6qJc3/se98y4OqFe+s9kneC fx90q6FFpzyO86JPK4Qa9KnbM3yLLoZj0FAud9/84Wujny2yEvFWUEJvvQcxPA6ODYon HZsVqZ0E+hM+4/beA/zUgPtF5yN+qJJZCkUgswN6zcCEj7l+KZaRBbK3zrWtGMNMyBJU glW4kTL76zyeZHsneQBoOszb1RchWHoYW3bDFjmaBpRzUkmzod+dNamqQghs+VDavmE8 VS9w== X-Gm-Message-State: ALoCoQnKlCFqBV8KCyzvzwi6RrykNrReSJY0HhSv7p0b1PP9D5jdyh22MedCrpSmzeEav75/oRIH X-Received: by 10.182.52.132 with SMTP id t4mr4627248obo.16.1444859196319; Wed, 14 Oct 2015 14:46:36 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.33.9 with SMTP id h9ls298763ioh.73.gmail; Wed, 14 Oct 2015 14:46:35 -0700 (PDT) X-Received: by 10.50.131.164 with SMTP id on4mr424952igb.8.1444859195551; Wed, 14 Oct 2015 14:46:35 -0700 (PDT) In-Reply-To: X-Original-Sender: Evgeny.Panasyuk@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:21796 Archived-At: ------=_Part_13_761263283.1444859194339 Content-Type: multipart/alternative; boundary="----=_Part_14_914823304.1444859194340" ------=_Part_14_914823304.1444859194340 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 15 October 2015 =D0=B3., 0:18:21 UTC+3 Ville Voutilainen: > > On 15 October 2015 at 00:09, Evgeny Panasyuk > wrote:=20 > > 14 October 2015 =D0=B3., 10:42:53 UTC+3 Ville Voutilainen :=20 > >>=20 > >>=20 > >> As far as having the concrete type goes, that sounds like it requires= =20 > even=20 > >> more inlining and across-call-stack transparency.=20 > >=20 > >=20 > > It actually requires less inlining and transparency. For instance, this= =20 > > code:=20 > > future concrete_coroutine()=20 > > {=20 > > int local =3D await async_operation();=20 > > return local;=20 > > }=20 > > Can be straightforwardly transformed to something like:=20 > > struct concrete_coroutine=20 > > {=20 > > state_value_type current_state;=20 > > int local;=20 > >=20 > > future method_state_machine(); // or operator()()=20 > > };=20 > > Where method_state_machine can be compiled separately, in another=20 > > translation unit.=20 > > And actually this approach is already implementable with macros, to som= e=20 > > extent (it works, but compiler-side transformation will give better=20 > result).=20 > > Where does this transformation happen translation-unit-wise, and how=20 > would the method_state_machine get compiled in a different translation=20 > unit? This is a good point. Looks like such transformation should happen in each= =20 translation unit which uses it - in order to deduce size of structure=20 (maybe not full code generation, just analysis of locals). Method itself=20 can be compiled only in one of translation units using mechanism similar to= =20 extern and explicit instantiation. But my point still holds, this method can be not inlined (in optimizer=20 sense) and still produce zero allocations. =20 > What type does the caller of the previous concrete_coroutine() see?=20 > > What do you mean? Which "previous"? =20 > >> In a stackless coroutine,=20 > >> the erased type combined with elision of the erasure and allocations= =20 > >> avoids=20 > >> having all coroutines have a different type.=20 > > Yes, but it is easy to get erased type from concrete when needed.=20 > > For instance different lambdas have different types, but can be easily= =20 > > placed into std::function (if has appropriate signature).=20 > > For some values of "easily". For the many users who don't care about the= =20 > underlying type of the coroutine, it's not so easy when they have to wrap= =20 > every=20 > time they use a coroutine.=20 > It can be done even without explicit wrapping, but just relying on=20 different coroutine_traits specializations. One trait may give concrete=20 coroutine type, and another can erase concrete and give erased type to user= .. For instance: concrete_generator cg1() { yield 1; } concrete_generator cg2() { yield 2; } Here cg1 and cg2 are different types. But here: type_erased_generator teg1() { yield 1; } type_erased_generator teg2() { yield 2; } teg1 and teg2 would have same type. User do not have to wrap manually cg1 and cg2 (but he can do this also) -= =20 instead he may use type_erased_generator from the start, and it will do=20 type erasure itself via coroutine_traits mechanism. --=20 ---=20 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 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-proposa= ls/. ------=_Part_14_914823304.1444859194340 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 15 October 2015 =D0=B3., 0:18:21 UTC+3 Ville Voutilainen:
On 15 October 2015 at 00:09, Evgeny Panasyuk &l= t;evg= eny....@gmail.com> wrote:
> =C2=A014 October 2015 =D0=B3., 10:42:53 UTC+3 Ville Voutilainen :
>>
>>
>> As far as having the concrete type goes, that sounds like it r= equires even
>> more inlining and across-call-stack transparency.
>
>
> It actually requires less inlining and transparency. For instance,= this
> code:
> future<int> concrete_coroutine()
> {
> =C2=A0 =C2=A0 int local =3D await async_operation();
> =C2=A0 =C2=A0 return local;
> }
> Can be straightforwardly transformed to something like:
> struct concrete_coroutine
> {
> =C2=A0 =C2=A0 state_value_type current_state;
> =C2=A0 =C2=A0 int local;
>
> =C2=A0 =C2=A0 future<int> method_state_machine(); // or oper= ator()()
> };
> Where method_state_machine can be compiled separately, in another
> translation unit.
> And actually this approach is already implementable with macros, t= o some
> extent (it works, but compiler-side transformation will give bette= r result).

Where does this transformation happen translation-unit-wise, and how
would the method_state_machine get compiled in a different translation
unit?

This is a good point. Looks like such transf= ormation should happen in each translation unit which uses it - in order to= deduce size of structure (maybe not full code generation, just analysis of= locals). Method itself can be compiled only in one of translation units us= ing mechanism similar to extern and explicit instantiation.
But my point= still holds, this method can be not inlined (in optimizer sense) and still= produce zero allocations.
=C2=A0
What type does the caller of the previous concrete_coroutine() = see?


What do you mean? Which "previous"?
= =C2=A0
>> In a stac= kless coroutine,
>> the erased type combined with elision of the erasure and alloc= ations
>> avoids
>> having all coroutines have a different type.
> Yes, but it is easy to get erased type from concrete when needed.
> For instance different lambdas have different types, but can be ea= sily
> placed into std::function (if has appropriate signature).

For some values of "easily". For the many users who don't= care about the
underlying type of the coroutine, it's not so easy when they have t= o wrap every
time they use a coroutine.

It can be done even without explicit wrapping, bu= t just relying on different coroutine_traits specializations. One trait may= give concrete coroutine type, and another can erase concrete and give eras= ed type to user.
For instance:
concrete_generator<int> cg1()
{
=C2=A0 =C2=A0 yield 1= ;
}

concrete_generator= <int> cg2()
{
=C2=A0 =C2=A0 yield 2;
}=
Here cg1 and cg2 are different types.<= br>
But here:
type_erased_generator<int> teg1()
{
=C2=A0 =C2=A0 yield 1;}<= span style=3D"color: #000;" class=3D"styled-by-prettify">

type_erased_generator<int> teg2()
{
=C2=A0 =C2=A0 yield 2;
}
= teg1 and teg2 would have same type.

User do not have to wrap manuall= y cg1 and cg2 (but he can do this also) - instead he may use type_erased_ge= nerator from the start, and it will do type erasure itself via coroutine_tr= aits mechanism.

--

---
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_14_914823304.1444859194340-- ------=_Part_13_761263283.1444859194339-- .