220 21783 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 11:29:22 -0700 (PDT) Lines: 524 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_418_1074316711.1444847362386" X-Trace: ger.gmane.org 1444847367 641 80.91.229.3 (14 Oct 2015 18:29:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 18:29:27 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC54TLGKR4LBBA567KYAKGQEDXKRUWI@isocpp.org Wed Oct 14 20:29:27 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f70.google.com ([209.85.220.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZmQnm-0007WY-2W for gclcip-std-proposals@m.gmane.org; Wed, 14 Oct 2015 20:29:26 +0200 Original-Received: by palb17 with SMTP id b17sf105771794pal.3 for ; Wed, 14 Oct 2015 11:29:24 -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=XM41U84l9r/c7FalPfLB8QG76WLKu5KLjefUheL6Nnk=; b=xlTM5O4yOzQEoLatrCheErKyZXxqQCoAMv2vCRtRHY50N7lXuka2WKAO86cANAHuK3 tZJUPXgiexIxBaUvaoQ74c6Fsrg27DBX1NpOAF9ZzSjIMrF9rrsPdzZy8YjadIZLZtEK PS1BYVQyxpdq/yp6rqB88vaXgdZORmnBzOUhGvepRJ8w6146ImLSIEeXPRpjJ4TTHk1X hboqbpLopmbzTUd0cJ+FI0RvVTxbBPPbBu1Jl5vJk/yqI9S2BvHBRiosCHkk7lvc/UAF vYGKRAUI/zCR4i3uEGlyChG5sRIFPg0rsAloY/xVqGqOfleLDjgr66dAsWb/F9XHTMdU +s3A== 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=XM41U84l9r/c7FalPfLB8QG76WLKu5KLjefUheL6Nnk=; b=aSbamqeDA2fdmohnNITbAFOZVuZZoQ1B4c4MrPbF6sHpkWAR2Z4LW/pJXPL5g5K8yq 8wUxF9O84iYq7tEUVKnLHrUZt1OEv+ScgCbB93K/WGojtfc0zf6QIRzTZL+rntvgqIVR z/eRgQ4287Zuv4+FX5fxC0pTUpn1QGNkXS4M97nkdcZrkC6i48JJiX9AXqBCn9geP0Jw 59WlYGOmH2NRxaSG6iKHMatm6Hm6FKSiyeVtHMWsB40UAgsQ8ZcPcjZVzBOmhdrCyLcm 1toXgR6VlKQD6iy04ghC6dHukdguZ1SV53JH3E5iP2pBzUIlfs94bD7sBtnsK8SmNKQ6 pLyQ== X-Gm-Message-State: ALoCoQkWR4NWe507qWtfrsYnc9t2KZg5tfrk3FjLMfBCAmi8NUEctJqbR2hC8jgT5DcRg/RLvHB8 X-Received: by 10.66.229.69 with SMTP id so5mr3874459pac.26.1444847364665; Wed, 14 Oct 2015 11:29:24 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.20.201 with SMTP id p9ls253035ige.44.gmail; Wed, 14 Oct 2015 11:29:23 -0700 (PDT) X-Received: by 10.50.73.233 with SMTP id o9mr73539igv.6.1444847363316; Wed, 14 Oct 2015 11:29:23 -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:21783 Archived-At: ------=_Part_418_1074316711.1444847362386 Content-Type: multipart/alternative; boundary="----=_Part_419_1957335235.1444847362387" ------=_Part_419_1957335235.1444847362387 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 14 October 2015 =D0=B3., 7:46:51 UTC+3 Nicol Bolas : > > > Thus far, including in this post, you haven't mentioned an example that= =20 > would actually compile. > > Actually examples do compile and do run. =20 > You linked to some macro code, but macros are, basically, *cheating*.=20 > They get to break all kinds of C++ rules, which an actual language featur= e=20 > would not. > Macros allow us to emulate language feature, to test it now, with current= =20 compilers. Even Stroustrup uses macros in Mach7 library to emulate language= =20 feature. I think it is obvious that following macro-based code: COROUTINE(vector, list_demo, (int, param), (int, local_x) (int, local_y)) { AWAIT(local_x =3D) vector{1,2,3}; AWAIT(local_y =3D) vector{10, 20, 30}; RETURN(local_x + local_y + param); } COROUTINE_END; Is equivalent to following code with language support: vector list_demo(int param) { int local_x =3D await vector{1,2,3}; int local_y =3D await vector{10, 20, 30}; =20 return local_x + local_y + param; } And if macro-based version does work, then this one will work without=20 problems. =20 > >> >=20 >> > Also... how does `vector` make any kind of sense with regar= d=20 >> > to P0114? The type isn't type erased, so each coroutine has its own=20 >> > type. Therefore, in order to put them in a homogeneous container like= =20 >> > `vector`, you'll have to type-erase them. Which requires memory=20 >> allocation.=20 >> > At which point, your version gains /nothing/ over P0057.=20 >> >> Same coroutines have same concrete types. For instance, with P0114 it=20 >> may be:=20 >> |=20 >> struct concrete_coroutine=20 >> {=20 >> resumable auto r =3D expression;=20 >> // ...=20 >> };=20 >> ...=20 >> make_unique(N);=20 >> | >> > > `auto` doesn't work that way. Non-static data members cannot be `auto`.= =20 > Normally I wouldn't care about a small issue like that, but it basically= =20 > makes your code impossible. > Such usage of auto is at p0114r0.pdf at page 11. =20 > > Without `auto` NSDMI (and I wouldn't hold my breath on seeing it=20 > ),=20 > you can't store a resumable expression. So you can't make containers of= =20 > them. > > Unless you erase their types. So again, you've gained *nothing*. > > Your macro solution gets around this because it uses macros. > =20 > I showed two versions above - macro based version and possible syntax with= =20 language support. Do you have any concrete reasoning why it would be impossible without=20 macros? =20 > Again, I am not talking specifically about P0114. Even P0057 can be=20 >> changed to have concrete coroutine type.=20 >> > > I'd be curious to see how, exactly. > > Currently it works like this: struct generator { ... coroutine_handle coro; }; generator example_generator() { yield 1; } int main() { generator x =3D example_generator(); x.move_next(); g.current_value(); } With concrete coroutine type it could be something like this: template class coroutine_value> struct generator { ... coroutine_value coro; }; generator example_generator() { yield 1; } // example_generator is transformed to: using example_generator =3D generator< synthesized_coroutine >; int main() { example_generator x{}; x.move_next(); g.current_value(); } =20 > > If you want this done, then you're going to need to go through the effort= =20 > of designing the feature to work without type erasure. Then you have to g= et=20 > someone to implement it. > It could be implemented even with macros, to some extent. And I think=20 macro-based solution is enough for proof-of-concept. =20 > Then, you can know whether it works just as well as P0057, whether it's= =20 > equally easy to use, and how much of a performance advantage it gets. > > If any. > Of course it gives performance advantage, because does not impose extra=20 mandatory allocation.=20 --=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_419_1957335235.1444847362387 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
14 October 2015 =D0=B3., 7:46:51 UTC+3 Nicol Bolas :
Thus far, including in this= post, you haven't mentioned an example that would actually compile.

Actually examples do compile and do run.=C2=A0
You linked = to some macro code, but macros are, basically, cheating. They get to= break all kinds of C++ rules, which an actual language feature would not.<= br>

Macros allow us to emulate language feature,= to test it now, with current compilers. Even Stroustrup uses macros in Mac= h7 library to emulate language feature.
I think it is obvious that follo= wing macro-based code:
COROUTINE(vector= <int>, list_de= mo,= (int, param),
=C2=A0 =C2=A0 (int, loca= l_x)
=C2=A0 =C2= =A0 (int, local_y))
{
=C2=A0 =C2=A0 AWAIT(local_x =3D) vector<int>{1,<= /span>2,3};
=C2=A0 =C2=A0 AWAIT(local_y =3D) vector<int>{10, = 20<= span style=3D"color: #660;" class=3D"styled-by-prettify">, 30};

=C2=A0 =C2=A0 RETURN(local_x + local_y + param);
}
COROUTIN= E_END;

Is equivalent to following code with language sup= port:

vector&= lt;int>= list_demo= (int param)
{
=C2=A0 =C2=A0 int local_x =3D await vector<int>{1,2,3};
=C2=A0 =C2=A0 int local_y =3D await vector<int>{10, 20,<= /span> 30};
=C2=A0 =C2=A0
=C2=A0 =C2=A0 <= /span>return local_x + local_y + param;
}

And if macro-based version do= es work, then this one will work without problems.


=C2=A0
>
> Also... how does `vector<coroutine>` make any kind of sense = with regard
> to P0114? The type isn't type erased, so each coroutine has it= s own
> type. Therefore, in order to put them in a homogeneous container l= ike
> `vector`, you'll have to type-erase them. Which requires memor= y allocation.
=C2=A0> At which point, your version gains /nothing/ over P0057.

Same coroutines have same concrete types. For instance, with P0114 it= =20
may be:
|
struct concrete_coroutine
{
=C2=A0 =C2=A0 =C2=A0resumable auto r =3D expression;
=C2=A0 =C2=A0 =C2=A0// ...
};
...
make_unique<concrete_coroutine[]>(N);
|

`auto` doesn't work that way. Non-static= data members cannot be `auto`. Normally I wouldn't care about a small = issue like that, but it basically makes your code impossible.


Such usage of auto is at p0114r0.pdf at page 11.
= =C2=A0

Without `= auto` NSDMI (and I wouldn&= #39;t hold my breath on seeing it), you can't store a resumable exp= ression. So you can't make containers of them.

Unless you erase = their types. So again, you've gained nothing.

Your macro = solution gets around this because it uses macros.
=C2=A0

I showed two versions above - macro based version an= d possible syntax with language support.
Do you have any concrete reason= ing why it would be impossible without macros?
=C2=A0
Again, I am not talking specifically about P0114. Even P0057 can be=20
changed to have concrete coroutine type.

I'd be curious to see how, exactly.


Currently it works like this:
struct generator
{
=C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0coro= utine_handle<promise_type> coro;};

generato= r example_generator()
{
=C2=A0 =C2= =A0 yield<= /span> 1;
}

int main()
{<= /span>
=C2=A0 = =C2=A0 generator x =3D example_generator();
=C2=A0 =C2=A0 x.move_next();
= =C2=A0 =C2=A0 g.curr= ent_value(= );
}

With concrete coroutine type it could be something like this:
templat= e<template= <typename><= /span> class coroutine_value>
struct generator
{
=C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0coroutine= _value<= promise_type> coro;
};

generator exam= ple_generator()
<= /span>{
=C2=A0 =C2=A0 yield= 1;
}
// example_generator is transformed to:
using example_generator =3D generator< synthesized_coroutine >;

int main()
{
= =C2=A0 =C2=A0 example_generator x{};
=C2=A0 =C2=A0 x.move_next();
=C2=A0 =C2=A0 g.current_value();
}=

=C2=A0

If you want this done, then you're going to need to go t= hrough the effort of designing the feature to work without type erasure. Th= en you have to get someone to implement it.

It c= ould be implemented even with macros, to some extent. And I think macro-bas= ed solution is enough for proof-of-concept.
=C2=A0
Then, you can know whether it works just = as well as P0057, whether it's equally easy to use, and how much of a p= erformance advantage it gets.

If any.
Of course it gives performance advantage, because does not impose extra ma= ndatory allocation.

--

---
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_419_1957335235.1444847362387-- ------=_Part_418_1074316711.1444847362386-- .