220 14208 <40b956e0-af26-42db-a9f1-ce327e47e6ef@isocpp.org> article Path: news.gmane.org!not-for-mail From: Gor Nishanov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: =?ISO-8859-1?Q?=5Bstd=2Dproposals=5D_Re=3A_Question_for_Germ=E1n_Diago=3A_N413?= =?ISO-8859-1?Q?4_and_N4244?= Date: Sat, 25 Oct 2014 07:30:14 -0700 (PDT) Lines: 765 Approved: news@gmane.org Message-ID: <40b956e0-af26-42db-a9f1-ce327e47e6ef@isocpp.org> References: <44e2f2f7-aff5-4cfa-86ff-aefad5b971ab@isocpp.org> <1ae62993-e2dc-4a1c-a1c3-4720cf56f9b0@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1911_1339040544.1414247414034" X-Trace: ger.gmane.org 1414247424 4174 80.91.229.3 (25 Oct 2014 14:30:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Oct 2014 14:30:24 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC47RF4IW4GRB57HV2RAKGQEC6HCDHI@isocpp.org Sat Oct 25 16:30:17 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yh0-f72.google.com ([209.85.213.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xi2MD-0006UM-Ah for gclcip-std-proposals@m.gmane.org; Sat, 25 Oct 2014 16:30:17 +0200 Original-Received: by mail-yh0-f72.google.com with SMTP id a41sf9931919yho.3 for ; Sat, 25 Oct 2014 07:30:16 -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 :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=ZZ2DB9yZaAvKg43Eaw953zIZG+8TRNsiMiLroSLJXr4=; b=Mi2H6tbKz8V0PfV9HJPfuPQ9uFhIBVOxI/LmRwUoTXGx+75bbDiCYdcc+MIFDMibml cpk6obLVgTfKN6kHZe2BTPkzoJoNlj78MofQlsybMsLPcZk78XIe47HwOLuR3MCOt/zy WB01PyzTgFA90hMp/u9jOYM8LjeQ9z1vmif/e+pcLdZbNmZ7ICqREtkBfUBQ2p4hx/ba GcWsF8OjPsuVWmcl3CQxZQxGzj4dD6CCgYcyVi9mGiC2bG+k0XOpMve4Pz8BxefOP9tG 3vVKi1v3pzM5dcCVi+dVkBgnOi5KQKqSKXfXr6mHHZpk4mXi8VtuW3a/TzV2LhKa/HJm /DPw== 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:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=ZZ2DB9yZaAvKg43Eaw953zIZG+8TRNsiMiLroSLJXr4=; b=cWpn3XCkNEzgkodkwdzt+Hcu+5m4Z4uFqtMuwU0RcY5Tvn9Vj1nF8TkzTp9aZH0xsP l9r1zzjyNHB0njKODzdj6m43FYLihECaVUHSLTQ6ZpxPM14eEsHL3SwAaWiNELQ6+g9B GrwZTN/8/PnO8sXACAsD23zztkXJSKyiuriEiLneXSc+Za0cbcqTrNQTKMe3kV9U3suI q1B0GRkoNJ7OATROiy5YAckRl6ryFrcKkFkkya2n/IHZVzIKfwyYzJDgQmhFrZrW9j6p H1tra0ceORsC7moV208sEblQmg8N5zt6HsuXpRFu4HQ04YYNhAMnZGyX/hLIqCDyO2PD VtwA== X-Gm-Message-State: ALoCoQlQLk/w3jzKBFN8xM4HTu5vwYRQ4vThFNxER1TG6GURxmWjV8o2ZGctxXS2Mx+OKTfIRZ+b X-Received: by 10.52.17.170 with SMTP id p10mr12467664vdd.6.1414247416375; Sat, 25 Oct 2014 07:30:16 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.40.202 with SMTP id o193ls1474461ioo.10.gmail; Sat, 25 Oct 2014 07:30:15 -0700 (PDT) X-Received: by 10.50.134.69 with SMTP id pi5mr119651igb.2.1414247415648; Sat, 25 Oct 2014 07:30:15 -0700 (PDT) In-Reply-To: <1ae62993-e2dc-4a1c-a1c3-4720cf56f9b0@isocpp.org> X-Original-Sender: GorNishanov@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:14208 Archived-At: ------=_Part_1911_1339040544.1414247414034 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =20 =20 1.=20 =20 Unspecified memory representation. That is a criticism of N3977 and=20 inapplicable to N4134. =20 2.=20 =20 Does N4134 need runtime support? =20 As much run-time support as range-based for. At compile time we look up= =20 await_xxx functions that explain how to await on a particular expression= ..=20 This is similar how range-based for looks up begin/end to understand how= to=20 iterate over a range =20 3. Difficult to reason about: "In my opinion, N4244 seems easier to reason= =20 about in the sense that I do know what is happening under the hood, because= =20 everything is modeled after a lambda. I do understand this model and I am= =20 confident is as lightweight as it can be.=20 =20 I started the design on N4134, with an attempt to generalize the lambda. I= =20 called it lambda*. This lambda*=E2=80=99s closure would contain not only th= e=20 capture, but also a room for all the locals in the body of operator().=20 Essentially, same idea as N4244. However, when applying to different=20 patterns, it seemed to me that nearly always it needed to be wrapped in=20 some kind of helper function that frequently need to allocate the memory=20 for lambda somewhere to give it a stable location. You can think of N4134 is a syntactic sugar wrapper around a lambda, such= =20 as in N4244. In case, where lifetime of a coroutine is fully contained in the lifetime= =20 of a calling function, heap allocation is elided and it becomes exactly the= =20 lambda*. I did not find a case where I needed to expose lambda* itself.=20 =20 =20 template async_generator> Timestamp(async_read_stream S)=20 { for await(v: S) yield {v, system_clock::now()}; } the body states very succinctly what it is doing. For every v received from= =20 S yield a pair of values v received and a timestamp when it was received. I= =20 can also rewrite it as: auto Timestamp(async_read_stream S) { for await(v: S) yield make_pair(v, system_clock::now()); } If you want to know what happens "under the hood" for await-for a yield,=20 look for the details in N4134. =20 On page 16 of N4134, you can see the expansion of await-for which is nearly= =20 the same as range-based for with the exception that every =E2=80=9Casyn pul= l=E2=80=9D=20 operation is annotated with =E2=80=9Cawait=E2=80=9D =20 *for await *( for-range-declaration : *expression *) statement =20 is equivalent to =20 { *auto *&& __range =3D *expression*; *for *( *auto *__begin =3D *await *begin-expr, __end =3D end-expr; __begin !=3D __end; *await *++__begin ) { *for-range-declaration *=3D *__begin; statement } } On page 15, there is a decription of what happens for yield: A yield statement is a statement of form: *yield **expression*; or *yield **braced-init-list*; yield ; is equivalent to (void)(await .yield_value()) Where a refers to the coroutine promise of the enclosing=20 resumable function. >> I can't figure out how this is implemented. Sorry if I don't fully=20 understand things yet. Think of N4134 as range-based for on steroids. It is mostly syntactic sugar= =20 and efficient suspend and resume giving the library designer to imbue=20 coroutines with meaning.=20 =20 Full implementation of generator is listed in Appendix A of N4134, also,=20 you can find there adapters to boost::futures and other things. =20 Are both implementations equivalente in expressive power? In my, biased, J view. N4134 can solve any problem that N4244 can with=20 shorter code and the same or better performance. The opposite is not true. Also, N4134 machinery is applicable to other problems domain, besides=20 coroutine and async. For example, Geoffrey Romer noticed that he can adapt= =20 await to simplify working with monadic classes such as optional. =20 optional FooSource(); optional BarFromFoo(const Foo&); ~~~~~~~~~~~~~~~~~~~~~~~~~~ with await ~~~~~~~~~~ optional f() { Bar bar =3D await BarFromFoo(await FooSource()); Baz baz; // Compute baz from bar return baz; } ~~~~~~~~~~~~~~~~~~~~~~~~~~~without await ~~~~~~~~ optional f() { optional foo =3D FooSource(); if (!foo) { return nullopt; } optional bar =3D BarFromFoo(*foo); if (!bar) { return nullopt; } Baz baz; // Compute baz from *bar return baz; } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 On Saturday, October 25, 2014 2:58:08 AM UTC-7, Germ=C3=A1n Diago wrote: > > Forgot one question: > > Are both implementations equivalente in expressive power? > > Regards, > Germ=C3=A1n Diago G=C3=B3mez > --=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_1911_1339040544.1414247414034 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

  1. Unspecified memory representation. That is a criticism of N3977 and inapplicable to N4134.

  2. D= oes N4134 need runtime support?

    As much run-time support as ran= ge-based for. At compile time we look up await_xxx functions that explain how to await on a particular expression. This is similar how range-based for looks up begin/e= nd to understand how to iterate over a range

3. Diff= icult to reason about: "In my opinion, N4244 seems easier to reason about in the sense that I do know what is happening under the hood, because everything is modeled after a lambda. I do understa= nd this model and I am confident is as lightweight as it can be.

&= nbsp;

I started the design on N4134, with an attempt to generalize the lambda. I called it lambda*. This lambda*=E2=80=99s closu= re would contain not only the capture, but also a room for all the locals in the bod= y of operator(). Essentially, same idea as N4244. However, when applying to different patterns, it seemed to me that nearly always it needed to be wrap= ped in some kind of helper function that frequently need to allocate the memory= for lambda somewhere to give it a stable location.

You can think of N4134 is a syntactic sugar wrapper around a lambda, such as in N4244.

In case, where lifetime of a coroutine is fully contained in the lifetime o= f a calling function, heap allocation is elided and it becomes exactly the lamb= da*.

I did not find a case where I needed to expose lambda* itself.

<= font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

&= nbsp;

t= emplate<class T>

a= sync_generator<pair<T, system_clock::time_point>>

T= imestamp(async_read_stream<T> S) 

{=

&= nbsp;   for await(v: S) yield {v, system_clock::now()};

}
the body states very succinctly what it is doing. For every v rece= ived from S yield a pair of values v received and a timestamp when it was r= eceived. I can also rewrite it as:

auto Timestamp(async_read_strea= m<T> S)  {

    for await(v: S) yield make_pair(v, system_clock::now= ());

=
}

If you want to know what happens "under the hood" for a= wait-for a yield, look for the details in N4134.
<= font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

&= nbsp;

O= n page 16 of N4134, you can see the expansion of await-for which is nearly the same as range-ba= sed for with the exception that every =E2=80=9Casyn pull=E2=80=9D operation is = annotated with =E2=80=9Cawait=E2=80=9D

&= nbsp;

for await ( for-range-declaration= : expression ) statement

 

 &nb= sp;   is equivalent to

 

{

auto && __range =3D= expression;

for ( auto __begin =3D await begin-e= xpr,

__end =3D end-expr;

__begin !=3D __end;

await <= /b>+= +__begin )

{

for-range-declaration =3D= *__begin;

statement

}

}


On page 15, there is a decription of what happens for yield:

A yield statement is a statement of form:

yield expression;<= /p>

or

yield braced-init-list;

yi= eld <something>; is equivalent to

(void)(await <Promise>.yield_value(<something>= ;))

Where a <Promise> refers to the coroutine promise of the enclosing= resumable function.

<= br>

&= gt;> I can't figure out how this is implemented. Sorry if I don't fully understand things yet.


Think of N4134 as range-based for on steroids. It is mostly syntactic sugar and efficient suspend and resume giving the library designer to imbue coroutines with meaning.

&= nbsp;

F= ull implementation of generator is listed in Appendix A of N4134, also, you can find there adapte= rs to boost::futures and other things.

&= nbsp;

view. N4134 can solve any problem that N4244 can with s= horter code and the same or better performance. The opposite is not true.