220 21403 <8067ed4f-3f08-41eb-b897-0760690fd55e@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Resumable expressions p0114r0 vs async/await P0057R0 Date: Wed, 7 Oct 2015 07:39:06 -0700 (PDT) Lines: 381 Approved: news@gmane.org Message-ID: <8067ed4f-3f08-41eb-b897-0760690fd55e@isocpp.org> References: <639f0012-8cb4-4db3-82a6-8d042a3497f9@isocpp.org> <401aa118-ed0b-4c7b-92cf-3fbd706eff9d@isocpp.org> <1d15dbc4-e0c1-4df1-86db-014e11f14d26@isocpp.org> <1bf00a8f-5f20-43de-a319-2712ab34eafd@isocpp.org> <36f46c03-b1f1-4230-b686-a7a9a1c491cb@isocpp.org> <9e17f8a6-4f5b-47dd-9f76-a4675a5ede3c@isocpp.org> <1105ae90-7e2b-49be-b88e-84493c9a1810@isocpp.org> <9838dc2a-6f1b-4dca-b4b9-72b6a9917c38@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_637_1122649585.1444228746758" X-Trace: ger.gmane.org 1444228767 31202 80.91.229.3 (7 Oct 2015 14:39:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Oct 2015 14:39:27 +0000 (UTC) Cc: german.diago@hubblehome.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBDG52SYAKGQE2NM7EPI@isocpp.org Wed Oct 07 16:39:13 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f198.google.com ([209.85.214.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zjps5-0006fR-Rz for gclcip-std-proposals@m.gmane.org; Wed, 07 Oct 2015 16:39:10 +0200 Original-Received: by obol7 with SMTP id l7sf28870725obo.1 for ; Wed, 07 Oct 2015 07:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc: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=Dr4ZNbOqNwlnjkDBmd8kOVJ6djOQn2CneT0eekIo9vA=; b=rssfua/pgEoP8dwl4dluxJcifiSvVmLob/FLW62bEkKdnfIzBDgmAWlPVDPh9ebUMe i0KaaXBvFpybxw4Zb+g5BcL4A6ZsQPG8XEHHSrEbYyxZv8SJGObCYxy2Od556khh6dJe Jzk7RAsYmhGgNJwIAiccXeTfzLAyYgVAPTloZwcGP2VOoT9ShGCLSU28G52BGDRsbECv ZCStI6JEIE10IHABmfumBLJdk25QvZeqrA5Nmragu7Z57cz50skIBt66ILlWYAY3VD/i pBu/wLcruPuKVQftnYJ0d67omisQ3tDwcX8RZo94Zq7UqH0A9gQk356wZX94ibRFY5C7 uypQ== 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:cc: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=Dr4ZNbOqNwlnjkDBmd8kOVJ6djOQn2CneT0eekIo9vA=; b=Z27B3wlKRsyhvne1AUp+l/pAAO6DN6MJIX5BLvbEnlDhdD/dujrHZWyB9wSZV1FwMM vvIh+k659N7JGaRLevSxWJ/IoTmtuy+TDNcI+yr/wAMp+f1pItPmCfM6x3c1Ur3B/gow jsxItY8NIJ9D5Z6n9nVjFCTm+0Z0ePJNDEUKcxMxHifxQZ9OM8NpQQ5bh2VmW9ucNCEm DJb64cu2q41Zg9soSJYBL6tmpUTD18DoOreWE5iZYMpyDbILm+SoFj/qn1NUSjnr5fkz 3lWxvr8U7NgBwKXKbCe0GF2U76Z/iWGT6P9XujHwqVvAzwZ5RhqxTPPY9bRfzaykJlLO mm4g== X-Gm-Message-State: ALoCoQn8clBM7iDbGTai3o0woLePKXScZbqgFdG1JiddYGc61xXhDXJ5GACZZVuMcRdV4OK0Qdue X-Received: by 10.182.44.228 with SMTP id h4mr1135912obm.5.1444228748901; Wed, 07 Oct 2015 07:39:08 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.1.113 with SMTP id 17ls189721igl.15.canary; Wed, 07 Oct 2015 07:39:08 -0700 (PDT) X-Received: by 10.50.79.166 with SMTP id k6mr138614igx.14.1444228748008; Wed, 07 Oct 2015 07:39:08 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:21403 Archived-At: ------=_Part_637_1122649585.1444228746758 Content-Type: multipart/alternative; boundary="----=_Part_638_1451834436.1444228746759" ------=_Part_638_1451834436.1444228746759 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, October 7, 2015 at 12:09:28 AM UTC-4, Germ=C3=A1n Diago wrote= : > > 3. no viral await when refactoring. >> >> >> You say that as though resumable expressions don't have their viral=20 >> aspects too. You can only call a resumable function as part of a resumab= le=20 >> context: either the calling function is resumable or the expression maki= ng=20 >> that call is resumable. Both of these require explicit annotation (excep= t=20 >> in those cases where the compiler magically works it out for you...=20 >> somehow). >> >> Oh sure, you won't be using `resumable` like you would `await`, or quite= =20 >> as much. But the fact is, you can't call a `resumable` function unless= =20 >> you've typed `resumable` somewhere nearby. So you still have to annotate= up=20 >> your call graph. And you still can't call coroutines of either kind with= out=20 >> some kind of annotation. >> > > I think that comparison is simply no honest: if you put await 7 levels=20 > down the stack, you need to decorate all the way up with await. > The way `await` works is that it halts the current function and returns=20 control to the calling function in such a way that the calling function can= =20 resume it later. Therefore, the only reason you would need to "put await 7 levels down the= =20 stack" is if you want every function in that call graph to halt when the=20 top-most function does, and thus return control to the caller "7 levels=20 down". Correct? If so: =20 > For resumable, you would need to do it in the 7th level only, and you > would not need to refactor the rest of the code. > That's not true. A function marked `resumable` can *only be called* from a resumable=20 context. This is either another function marked `resumable` or from an=20 expression marked `resumable`. So this is illegal: resumable int level3() { return 5; } int level2() { return level3(); //Cannot call a resumeable function here. } Therefore, *every one of those 7 levels* is going to have to be a=20 `resumable` function. So every one of those levels will have to mark their= =20 signature with `resumable`. Any code that calls into any one of those 7=20 levels will have to mark each use of them with `resumable`, or will=20 themselves have to be coroutines. So yes, it's just as viral. Only it's worse, because not only do you have= =20 to mark them `resumable`, they *must be inline*. The only saving grace you get is that the proposal allows automatic=20 deduction of resumeable functions. But not everywhere; only in template=20 code and lambdas. So normal functions don't provide this feature. That is 7 vs 1 refactoring. Needless to say the reusability problem that=20 > Chris exposes in the paper: you cannot reuse algorithms, for example,=20 > with await. > That helps demonstrate the viral nature of resumable expressions. If I call= =20 an algorithm that internally does an implicitly resumable operation, then= =20 that algorithm internally becomes a coroutine. It becomes resumable. Which means... I now *must* call that algorithm instantiation from a=20 resumable context. So either my function itself is `resumable`, or I have= =20 to say `resumable for_each(...)`. This doesn't invalidate your point, namely that algorithms will deduce how= =20 to properly be `resumable` for their contents. The exact suspend/resume=20 points will not be defined by the writer of the algorithm, but by the=20 functions the algorithm actually calls. And there is value to that. At this point, that is basically the only advantage of resumable=20 expressions. It's a non-trivial thing to be sure, but I don't see anything= =20 about resumable functions that would prevent you from addressing these=20 concerns there. What resumable functions lack relative to resumable expressions are two=20 things: 1) A way for a function to effectively force the caller to become a=20 coroutine (implicit await). 2) A way for the caller of a function to *reverse* the implicit `await` of= =20 a function call (that's what `resumable` applied to expressions does). These features are all it takes to allow for the kind of template code=20 reuse you're talking about. Though it does make it slightly more=20 inconvenient than the resumable expressions model, since RE coroutines=20 don't have return type requirements. But neither of these is *impossible* with the resumable functions model.=20 It's simply a matter of finding the best way to add those features in. And of deciding if we want them at all (that's not necessarily a given). You cannot have member variables with await either, right? > I don't know what you mean by this. =20 > These are all tangible benefits from having a function object as a=20 > representation. > .... huh? Those benefits have nothing to do with "having a function object= =20 as a representation." Those benefits come from having to declare whether a= =20 function is a coroutine at the function level, rather than in the=20 function's implementation. So I'm not seeing how that's a point in resumable expression's favor. >> > > You can see it: Imagine a deep stack of calls. How much refactoring do yo= u=20 > need in each of the proposals? Imagine code reuse: resumable expressions= =20 > can reuse code. > Code reuse in template functions, perhaps. Code reuse elsewhere? Not so=20 much. =20 > We cannot say the same about await *unless* I missed something. In the C+= +=20 > style, I think resumable functions are more well behaved than await, in t= he=20 > sense that > it is just a function object, you know what it is doing, you could make i= t=20 > (maybe in future proposals) copyable, movable, you know the representatio= n:=20 > jump point + strictly needed data. > I think the resumable expressions proposal puts the bar very high to the= =20 > rest of the proposals, because besides its benefits, you can also impleme= nt > what other proposals are proposing. > Yes, you could implement resumable functions on top of resumable=20 expressions. But that doesn't prove resumable expressions are better. Not= =20 does it prove that anything you could build atop resumable expressions=20 cannot also be built atop resumable functions. The thing is that there is one really important fact that cannot be gotten= =20 around. Resumable functions are a pretty-well proven concept. We have multiple=20 implementations of them, apparently. We have experience in implementing=20 them, with an evaluation of optimization opportunities. We have actual=20 standard wording for it. Can you tell me that resumable expressions have anywhere *near* the field= =20 experience? --=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_638_1451834436.1444228746759 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, October 7, 2015 at 12:09:28 AM UTC-4, Germ=C3=A1n Diago wrote= :
3. no viral await when refactoring.

You say that as= though resumable expressions don't have their viral aspects too. You c= an only call a resumable function as part of a resumable context: either th= e calling function is resumable or the expression making that call is resum= able. Both of these require explicit annotation (except in those cases wher= e the compiler magically works it out for you... somehow).

Oh sure, = you won't be using `resumable` like you would `await`, or quite as much= .. But the fact is, you can't call a `resumable` function unless you'= ;ve typed `resumable` somewhere nearby. So you still have to annotate up yo= ur call graph. And you still can't call coroutines of either kind witho= ut some kind of annotation.

I think th= at comparison is simply no honest: if you put await 7 levels down the stack= , you need to decorate all the way up with await.
The way `await` works is that it halts the current function and returns c= ontrol to the calling function in such a way that the calling function can = resume it later.

Therefore, the only reason you would need to "= put await 7 levels down the stack" is if you want every function in th= at call graph to halt when the top-most function does, and thus return cont= rol to the caller "7 levels down". Correct?

If so:
=C2= =A0
For resumable, y= ou would need to do it in the 7th level only, and you
would not need to = refactor the rest of the code.

That's not tr= ue.

A function marked `resumable` can only be called from a r= esumable context. This is either another function marked `resumable` or fro= m an expression marked `resumable`.

So this is illegal:

= resumable = int level3()
{
=C2=A0 return 5;}<= span style=3D"color: #000;" class=3D"styled-by-prettify">

int level2()
{
=C2=A0 return level3(); //Cannot call a resumeable function here.
}

Therefore, every one= of those 7 levels is going to have to be a `resumable` function. So ev= ery one of those levels will have to mark their signature with `resumable`.= Any code that calls into any one of those 7 levels will have to mark each = use of them with `resumable`, or will themselves have to be coroutines.
=
So yes, it's just as viral. Only it's worse, because not only d= o you have to mark them `resumable`, they must be inline.

The= only saving grace you get is that the proposal allows automatic deduction = of resumeable functions. But not everywhere; only in template code and lamb= das. So normal functions don't provide this feature.

That is 7 vs 1 refactoring. Ne= edless to say the reusability problem that Chris exposes in the paper: you = cannot reuse algorithms, for example,=C2=A0
with await.
That helps demonstrate the viral nature of resumable expressions. If I cal= l an algorithm that internally does an implicitly resumable operation, then= that algorithm internally becomes a coroutine. It becomes resumable.
Which means... I now must call that algorithm instantiation from a= resumable context. So either my function itself is `resumable`, or I have = to say `resumable for_each(...)`.

This doesn't invalidate your p= oint, namely that algorithms will deduce how to properly be `resumable` for= their contents. The exact suspend/resume points will not be defined by the= writer of the algorithm, but by the functions the algorithm actually calls= .. And there is value to that.

At this point, that is basically the o= nly advantage of resumable expressions. It's a non-trivial thing to be = sure, but I don't see anything about resumable functions that would pre= vent you from addressing these concerns there.

What resumable functi= ons lack relative to resumable expressions are two things:

1) A way = for a function to effectively force the caller to become a coroutine (impli= cit await).

2) A way for the caller of a function to reverse = the implicit `await` of a function call (that's what `resumable` applie= d to expressions does).

These features are all it takes to allow for= the kind of template code reuse you're talking about. Though it does m= ake it slightly more inconvenient than the resumable expressions model, sin= ce RE coroutines don't have return type requirements.

But neithe= r of these is impossible with the resumable functions model. It'= s simply a matter of finding the best way to add those features in.

= And of deciding if we want them at all (that's not necessarily a given)= ..

You cannot= have member variables with await either, right?
I don't know what you mean by this.
=C2=A0
These are all tangible benefits from havin= g a function object as a representation.

... huh= ? Those benefits have nothing to do with "having a function object as = a representation." Those benefits come from having to declare whether = a function is a coroutine at the function level, rather than in the functio= n's implementation.

So I'm not seeing how that's a point in resumable expression&= #39;s favor.

You can see it: Imagine a= deep stack of calls. How much refactoring do you need in each of the propo= sals? Imagine code reuse: resumable expressions can reuse code.

Code reuse in template functions, perhaps. Code reuse e= lsewhere? Not so much.
=C2=A0
We cannot say the same about await *unless* I missed something= .. In the C++ style, I think resumable functions are more well behaved than = await, in the sense that
it is just a function object, you know what it = is doing, you could make it (maybe in future proposals) copyable, movable, = you know the representation: jump point + strictly needed data.
I think = the resumable expressions proposal puts the bar very high to the rest of th= e proposals, because besides its benefits, you can also implement
what o= ther proposals are proposing.

Yes, you could= implement resumable functions on top of resumable expressions. But that do= esn't prove resumable expressions are better. Not does it prove that an= ything you could build atop resumable expressions cannot also be built atop= resumable functions.

The thing is that there is one really importan= t fact that cannot be gotten around.

Resumable functions are a prett= y-well proven concept. We have multiple implementations of them, apparently= .. We have experience in implementing them, with an evaluation of optimizati= on opportunities. We have actual standard wording for it.

Can you te= ll me that resumable expressions have anywhere near the field experi= ence?

--

---
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_638_1451834436.1444228746759-- ------=_Part_637_1122649585.1444228746758-- .