220 21406 article Path: news.gmane.org!not-for-mail From: german.diago@hubblehome.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Resumable expressions p0114r0 vs async/await P0057R0 Date: Wed, 7 Oct 2015 08:37:45 -0700 (PDT) Lines: 382 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> <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> <8067ed4f-3f08-41eb-b897-0760690fd55e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7595_1022848722.1444232265172" X-Trace: ger.gmane.org 1444232269 27406 80.91.229.3 (7 Oct 2015 15:37:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Oct 2015 15:37:49 +0000 (UTC) Cc: german.diago@hubblehome.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDKJVOEEVYNRBSPY2SYAKGQEKBOKQNQ@isocpp.org Wed Oct 07 17:37:48 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 1Zjqmp-0005YH-IZ for gclcip-std-proposals@m.gmane.org; Wed, 07 Oct 2015 17:37:47 +0200 Original-Received: by obbgf5 with SMTP id gf5sf30910104obb.3 for ; Wed, 07 Oct 2015 08:37:46 -0700 (PDT) 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=bcwcAw+O2oZtRUIX8lmhO1qXDOLFbv84ON9p4/kxxm0=; b=dpdGQO2a+gn8JgrisDGZyxUjMO7EpNCdiT8N91W2QGCIcXh3Colchwt800bT98/Ui7 /OmVNo0T6RMCk53rAyxQdEOu4LtDO81PtJG70Z3MpcAg1e7DpvNQuv0bR9kAUSL2kSZG YIFajKnKl2pS2gmRU1uYgheKSR6K9hg+WPoh1GyJLDnsz/xvqvuS1SAPwLNgPRtnDAIK sBlnESgP+rQAyJTUGmakhU+4lwQ0w4lQ0LzeMvF7e8hTYxc6cPK4sidxjWLJrGrn+ZZG fuAJXbJTNv/nQsfI8dHpZmac8pQo8ST2PKQyfdcF8hjF2Y/7rDQx/BMXWg3W3Sq3fUC2 9b4Q== X-Gm-Message-State: ALoCoQkEhw0grZ5TNk0V1B6EfEXNxXlWTwyOrtTQQN7+YFF5Nkhuwxb+V9G5W8IB/8apnaYgElgQ X-Received: by 10.182.65.134 with SMTP id x6mr1412777obs.14.1444232266608; Wed, 07 Oct 2015 08:37:46 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.131.21 with SMTP id f21ls247447iod.24.gmail; Wed, 07 Oct 2015 08:37:45 -0700 (PDT) X-Received: by 10.50.66.205 with SMTP id h13mr321893igt.10.1444232265639; Wed, 07 Oct 2015 08:37:45 -0700 (PDT) In-Reply-To: <8067ed4f-3f08-41eb-b897-0760690fd55e@isocpp.org> X-Original-Sender: german.diago@hubblehome.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:21406 Archived-At: ------=_Part_7595_1022848722.1444232265172 Content-Type: multipart/alternative; boundary="----=_Part_7596_406258332.1444232265173" ------=_Part_7596_406258332.1444232265173 Content-Type: text/plain; charset=UTF-8 > > Therefore, the only reason you would need to "put await 7 levels down the > stack" is if you want every function in that call graph to halt when the > top-most function does, and thus return control to the caller "7 levels > down". Correct? > > If so: > > >> 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. > As I understood it, maybe I am wrong, the function will suspend inside. > > A function marked `resumable` can *only be called* from a resumable > context. This is either another function marked `resumable` or from an > 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 > `resumable` function. So every 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 do you have > to mark them `resumable`, they *must be inline*. > > I am not sure about this limitation. I will take a look again. > The only saving grace you get is that the proposal allows automatic > deduction of resumeable functions. But not everywhere; only in template > code and lambdas. So normal functions don't provide this feature. > Now I understand why it works. I did not catch this at first. > > That is 7 vs 1 refactoring. Needless to say the reusability problem that >> Chris exposes in the paper: you cannot reuse algorithms, for example, >> > with await. >> > > That helps demonstrate the viral nature of resumable expressions. If I > call an algorithm that internally does an implicitly resumable operation, > then that algorithm internally becomes a coroutine. It becomes resumable. > Yes. True. Though, still more reusable than await in this regard. > > 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 point, 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. > Agree. > > At this point, that is basically the only advantage of resumable > expressions. It's a non-trivial thing to be sure, but I don't see anything > about resumable functions that would prevent you from addressing these > concerns there. > > What resumable functions lack relative to resumable expressions are two > things: > > 1) A way for a function to effectively force the caller to become a > coroutine (implicit await). > > 2) A way for the caller of a function to *reverse* the implicit `await` > of 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 > reuse you're talking about. Though it does make it slightly more > inconvenient than the resumable expressions model, since RE coroutines > don't have return type requirements. > > But neither of these is *impossible* with the resumable functions model. > It's simply a matter of finding the best way to add those features in. > Would be nice to have those. > > 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 mean a member variable that holds a resumable expression, you can have that, it is a function object. Can this be done with resumable functions? As far as I understand, but again, you seem to understand the proposal better than me, you can only store the result, but not the object itself. > > I don't know what you mean by this. > > >> These are all tangible benefits from having a function object as a >> representation. >> > > If you have a function object, we understand how to save it, reified (non-type erased) and how to extend that to a copyable, movable object when it makes sense. That is what I meant. > ... 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 > function's implementation. > > Code reuse in template functions, perhaps. Code reuse elsewhere? Not so > much. > All the STL is not a small thing to dismiss... Not to mention all the template libs there are in the wild. Yes, you could implement resumable functions on top of resumable > expressions. But that doesn't prove resumable expressions are better. Not > does it prove that anything you could build atop resumable expressions > cannot also be built atop resumable functions. > Maybe it is me only, but I find resumable expressions so easy to translate, in my head, to what it really is. I cannot say the same about await. It has its merits also, sure, but resumable expressions seem simpler to me, and everything else seems to be composable on top of it. Can you tell me that resumable expressions have anywhere *near* the field > experience? > Well, the closest thing we can have is creating function objects with stackless coroutines: http://www.boost.org/doc/libs/1_59_0/doc/html/boost_asio/overview/core/coroutine.html That is a function object with resumable feature. I think what a resumable expression does can fit in my head the same way a lambda fits. I cannot say the same when I reason about await. At least not so easily. And I am still not convinced about cannot hold it as an object (am I right?) you can only get its result, and the fact that you must type-erase it (sure, there are optimizations for that, but for now they are in MS compiler only?). Thank you very much for your feedback, it made me understand a few points I was wrong about. -- --- 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/. ------=_Part_7596_406258332.1444232265173 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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

If so:
=C2=A0
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.

As I understood it, maybe I am wrong, the function will sus= pend inside.
=C2=A0

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

So this is illegal:

<= div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187= );border-style:solid;border-width:1px;word-wrap:break-word">
resumable int level3()
{
=C2=A0 r= eturn 5= ;
}

= int lev= el2(){
= =C2=A0 return level3(); //Cannot call a resumeable func= tion here.
}
Therefore, every one of those 7 levels is going to have to be a `re= sumable` function. So every one of those levels will have to mark their sig= nature 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 ha= ve to be coroutines.

=C2=A0
So yes, it's just as viral. Only= it's worse, because not only do you have to mark them `resumable`, the= y must be inline.

I am not sure about= this limitation. I will take a look again.

=C2=A0=
The only saving gra= ce you get is that the proposal allows automatic deduction of resumeable fu= nctions. But not everywhere; only in template code and lambdas. So normal f= unctions don't provide this feature.

Now I understand why it works. I did not catch this at first.
=
=C2=A0

That is 7 vs 1 refactoring. = Needless to say the reusability problem that Chris exposes in the paper: yo= u cannot reuse algorithms, for example,=C2=A0
with await.

Th= at helps demonstrate the viral nature of resumable expressions. If I call a= n algorithm that internally does an implicitly resumable operation, then th= at algorithm internally becomes a coroutine. It becomes resumable.

Yes. True. Though, still more reusable th= an await in this regard.
=C2=A0

Which means... I now must call that algori= thm 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 point, namely that algorithms will deduce how to pro= perly be `resumable` for their contents. The exact suspend/resume points wi= ll not be defined by the writer of the algorithm, but by the functions the = algorithm actually calls. And there is value to that.

Agree.
=C2=A0

At this point, that is basically the only adva= ntage of resumable expressions. It's a non-trivial thing to be sure, bu= t I don't see anything about resumable functions that would prevent you= from addressing these concerns there.

What resumable functions lack= relative to resumable expressions are two things:

1) A way for a fu= nction to effectively force the caller to become a coroutine (implicit awai= t).

2) A way for the caller of a function to reverse the impl= icit `await` of a function call (that's what `resumable` applied to exp= ressions does).

These features are all it takes to allow for the kin= d of template code reuse you're talking about. Though it does make it s= lightly more inconvenient than the resumable expressions model, since RE co= routines don't have return type requirements.

=C2=A0
<= div>But neither of these is impossible with the resumable functions = model. It's simply a matter of finding the best way to add those featur= es in.

Would be nice to have thos= e.
=C2=A0
=
And of deciding if we want them at all (that's not necessarily a gi= ven).

You cannot = have member variables with await either, right?

I mean a member variable that holds a resumable exp= ression, you can have that, it is a function object.
Can this be = done with resumable functions? As far as I understand, but again, you seem<= /div>
to understand the proposal better than me, you can only store the= result, but not the object itself.

=C2=A0

I don't know what y= ou mean by this.
=C2=A0
These are all tangible benefits from having a function object as a repres= entation.

If you have a = function object, we understand how to save it, reified (non-type erased) an= d how to extend that to
a copyable, movable object when it makes = sense. That is what I meant.
=C2=A0
... huh? Those benefits have nothing to do with &= quot;having a function object as a representation." Those benefits com= e from having to declare whether a function is a coroutine at the function = level, rather than in the function's implementation.
=C2=A0
Code reuse in template functions, perhaps. Code reuse elsewhere? Not= so much.

All the STL is not a small = thing to dismiss... Not to mention all the template libs there are in the w= ild.
=C2=A0

Yes, you could implement resumable functions on top of res= umable expressions. But that doesn't prove resumable expressions are be= tter. Not does it prove that anything you could build atop resumable expres= sions cannot also be built atop resumable functions.
=

Maybe it is me only, but I find resumable expressions s= o easy to translate, in my head, to what it really is.
I cannot s= ay the same about await. It has its merits also, sure, but resumable expres= sions seem simpler to me,
and everything else seems to be composa= ble on top of it.
=C2=A0

Can you tell me that resumable expressions ha= ve anywhere near the field experience?

=C2=A0Well, the closest thing we can have is creating function obj= ects with stackless coroutines:=C2=A0http://www.boost.org/doc/libs/1_59_0/d= oc/html/boost_asio/overview/core/coroutine.html

Th= at is a function object with resumable feature. I think what a resumable ex= pression does can fit in my head
the same way a lambda fits.
I cannot say the same when I reason about await. At least not so easi= ly. And I am still not convinced about
cannot hold it as an objec= t (am I right?) you can only get its result, and the fact that you must typ= e-erase it
(sure, there are optimizations for that, but for now t= hey are in MS compiler only?).

Thank you very much= for your feedback, it made me understand a few points I was wrong about.
=C2=A0

--

---
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_7596_406258332.1444232265173-- ------=_Part_7595_1022848722.1444232265172-- .