220 21742 <9dd3f28c-4ffb-4e08-9955-242c46e14527@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: Tue, 13 Oct 2015 21:14:59 -0700 (PDT) Lines: 131 Approved: news@gmane.org Message-ID: <9dd3f28c-4ffb-4e08-9955-242c46e14527@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6550_746428769.1444796099213" X-Trace: ger.gmane.org 1444796110 30526 80.91.229.3 (14 Oct 2015 04:15:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 04:15:10 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC54TLGKR4LBBRFN66YAKGQEDFJ63CQ@isocpp.org Wed Oct 14 06:15:06 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f69.google.com ([209.85.218.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZmDSw-0000JO-2t for gclcip-std-proposals@m.gmane.org; Wed, 14 Oct 2015 06:15:02 +0200 Original-Received: by oiak8 with SMTP id k8sf59744783oia.0 for ; Tue, 13 Oct 2015 21:15:01 -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=/nfd/NI5oh8S9on5lfshrq5usMr4s0ndjyFVhGxVD3g=; b=gzB+nbb0Brqxr3v+oV0sCOHflQVCMGEPNgc3TUvg8ggKsLHIcsRExDLj8QY+NtVHJN KhrHg4fKdPTrrBULmOAVYTn5wvuGdbNfiYFdhgict06mCiDcTdsGlTXUJnhlQgysvhgN YmrZZxqVE70T4R03XCkEY8k6mR6tBu+xL/yXlYnsFkkJ5/+yZmflIEtkmyzzrPqZwfa9 F7n+lf5O1/6WrwEdXQq2xD6TTyq/6ZlK+Mr8Ft6rbcY4WlwLmdkZgac2VF+PEoZetIXa lFMuJf3ZwKKmwYlJGnjJHhAg8SPJwl7yHQmBZiQND3EQbea6TaAmNd3j6Wgg14ruj/Hy U+Zg== 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=/nfd/NI5oh8S9on5lfshrq5usMr4s0ndjyFVhGxVD3g=; b=E2iEVaAxlAKv6mnoluuWv8iHjDpxUtYLHY/tVfth/mNKa0zoMIVQrM2eDRUH5U4InV t4gyNz8cLKxTnjCq36S/JPLdUstKJstpRDEdFFaFeAK0mMTH0EU+4S95lz4/z/vVMZid bQkoMeJvN6OtC0SdQBQMhczXXNswPD4IgCKrz8GVcKi/g8srjPq79pUPO+eQtXoRh4Cr Q7fzi1FH3E4WAgUoIpOIqZbRIx1W+C0D08fZzQsEFM8b1WzW8Ade+1nqDTEQU+jeMA9l JXGmAMVc3aLO5f23thEiuvQN1FeytNeNCdYjg4jAggDN2ryBcRIsxguxtxxcu0E2HrzT 9i9w== X-Gm-Message-State: ALoCoQk4S61dPkOI9X1rxQeJx6Eio1Rr7JtITTHqtRap7YpEXLJ6AKEytT4DeLqUTSBR/PB0NMZM X-Received: by 10.107.164.154 with SMTP id d26mr1333244ioj.19.1444796101239; Tue, 13 Oct 2015 21:15:01 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.33.20 with SMTP id n20ls1603964igi.7.canary; Tue, 13 Oct 2015 21:15:00 -0700 (PDT) X-Received: by 10.50.103.102 with SMTP id fv6mr34760igb.12.1444796100268; Tue, 13 Oct 2015 21:15:00 -0700 (PDT) In-Reply-To: <510ce172-976a-4e3a-ae68-31fdb40af4d7@isocpp.org> 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:21742 Archived-At: ------=_Part_6550_746428769.1444796099213 Content-Type: multipart/alternative; boundary="----=_Part_6551_559606608.1444796099213" ------=_Part_6551_559606608.1444796099213 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 14 October 2015 =D0=B3., 6:50:16 UTC+3 Gor Nishanov : > > > > On Tuesday, October 13, 2015 at 8:17:53 PM UTC-7, Evgeny Panasyuk wrote: >> >> I am not talking specifically about P0114. I am talking about stackless= =20 >> coroutines with concrete non-type-erased types.=20 >> > > The starting point of my design was a lambda* with the properties you=20 > describe. When applied to problems I needed solving I found it=20 > unsatisfactory and therefore went with N4134 proposal. That does not mean= =20 > that at some point, somebody won't be able to invent a better lambda* and= =20 > get it standardized. > > Well, this is also the problem. If we already would have some stackless=20 coroutines in ISO - it would be much harder to get additional one into it. =20 > P0114, P0057 and lambda* are all powered by the same underlying machinery= ..=20 > A transformation of a state machine written in imperative fashion into an= =20 > actual state machine. The difference is in a public face of the state=20 > machine. You just need to figure out compelling use-cases and sane=20 > semantics that are not already covered efficiently by P0057 and write a= =20 > proposal. I cannot do it for you as the problems I need solving, namely= =20 > async I/O and async programming in general, are addressed by P0057=20 > succinctly and efficiently. > > If you need only async I/O - yes, I could imagine that extra allocation is= =20 tolerable in such context. But P0057 describes not only async I/O - but=20 also for instance generators. And for generators (like transform iterators)= =20 an extra allocation is huge price. It is acceptable price for languages like C# (especially taking into=20 account fast happy-path allocations in first generation of copying GC), but= =20 it is definitely not acceptable for C++ which has costly default=20 allocations and ambitious zero-overhead goal. And if you consider only performance of async I/O use cases - then I think= =20 proposal should directly reflect this somehow. --=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_6551_559606608.1444796099213 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
14 October 2015 =D0=B3., 6:50:16 UTC+3 Gor Nishanov :


On Tuesday= , October 13, 2015 at 8:17:53 PM UTC-7, Evgeny Panasyuk wrote:
I am not talking specifically about P0114. I am = talking about stackless=20
coroutines with concrete non-type-erased types.

The starting point of my design was a = lambda* with the properties you describe. When applied to problems I needed= solving I found it unsatisfactory and therefore went with N4134 proposal. = That does not mean that at some point, somebody won't be able to invent= a better lambda* and get it standardized.


Well, this is also the problem. If we already would hav= e some stackless coroutines in ISO - it would be much harder to get additio= nal one into it.
=C2=A0
P0114, P0057 and lambda* are all powered= by the same underlying machinery. A transformation of a state machine writ= ten in imperative fashion into an actual state machine. The difference is i= n a public face of the state machine. You just need to figure out compellin= g use-cases and sane semantics that are not already covered efficiently by = P0057 and write a proposal. I cannot do it for you as the problems I need s= olving, namely async I/O and async programming in general, are addressed by= P0057 succinctly and efficiently.

<= div>
If you need only async I/O - yes, I could imagine that extra alloca= tion is tolerable in such context. But P0057 describes not only async I/O -= but also for instance generators. And for generators (like transform itera= tors) an extra allocation is huge price.
It is acceptable price for lang= uages like C# (especially taking into account fast happy-path allocations i= n first generation of copying GC), but it is definitely not acceptable for = C++ which has costly default allocations and ambitious zero-overhead goal.<= br>
And if you consider only performance of async I/O use cases - then I= think proposal should directly reflect this somehow.

--

---
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_6551_559606608.1444796099213-- ------=_Part_6550_746428769.1444796099213-- .