220 21623 <561C213F.1060009@gmail.com> 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 00:08:15 +0300 Lines: 65 Approved: news@gmane.org Message-ID: <561C213F.1060009@gmail.com> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed X-Trace: ger.gmane.org 1444684111 11410 80.91.229.3 (12 Oct 2015 21:08:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Oct 2015 21:08:31 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC54TLGKR4LBBRGC6CYAKGQERJ3AEJI@isocpp.org Mon Oct 12 23:08:24 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f197.google.com ([209.85.212.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZlkKT-0002gE-T4 for gclcip-std-proposals@m.gmane.org; Mon, 12 Oct 2015 23:08:21 +0200 Original-Received: by wibzt1 with SMTP id zt1sf523965wib.0 for ; Mon, 12 Oct 2015 14:08:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=+4OX4kq17te0dxdMzfOoECcxQzoMFRn236Uca1u2xyE=; b=A4DHZC+wT6X082OAwxaJ6C5S1aSn8RDNgMp20p60Y4dJnzT0fALSCt/OKM6cOM2KJP eJT3I4qLuvn5M4qCOIGcuNGT6Qyci14DnfecDwghxJbZpLfrWqG0amPJ4Oy40edEZpuO HLM7XSlQRVExCgs3kQQ+oM8Z60satSBwSzJP5N4+Raoe/TzirgiSKT+UktPW3GSoT2f6 WZgp+yg5GK6xwce2qJQCMsfg/m/+ejDe37fzp3XVtGzBaTpBbmkN+TSOgEJF/IymPL9K s8VxuSAsGIflPzhCaryekeskrec+crBFDdrWMdQfIlkyOsmt2mbVO9W2cxgfgDiFjPLr hk6w= X-Gm-Message-State: ALoCoQkZLSpkUtKsJWNg8vtFcPK8wNp9442A2sGsOp+SYEfsa1rEAMER8OdBqDMCj2yucyecSzfW X-Received: by 10.112.202.165 with SMTP id kj5mr6063620lbc.5.1444684101476; Mon, 12 Oct 2015 14:08:21 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.164.135 with SMTP id n129ls589124lfe.7.gmail; Mon, 12 Oct 2015 14:08:20 -0700 (PDT) X-Received: by 10.112.55.2 with SMTP id n2mr13746361lbp.59.1444684100335; Mon, 12 Oct 2015 14:08:20 -0700 (PDT) Original-Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com. [2a00:1450:4010:c04::230]) by mx.google.com with ESMTPS id v80si12604272lfd.80.2015.10.12.14.08.20 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Oct 2015 14:08:20 -0700 (PDT) Received-SPF: pass (google.com: domain of evgeny.panasyuk@gmail.com designates 2a00:1450:4010:c04::230 as permitted sender) client-ip=2a00:1450:4010:c04::230; Original-Received: by lbbk10 with SMTP id k10so43097917lbb.0 for ; Mon, 12 Oct 2015 14:08:20 -0700 (PDT) X-Received: by 10.112.202.35 with SMTP id kf3mr13376644lbc.19.1444684100183; Mon, 12 Oct 2015 14:08:20 -0700 (PDT) Original-Received: from [192.168.0.186] ([31.23.182.83]) by smtp.googlemail.com with ESMTPSA id g141sm3242996lfe.38.2015.10.12.14.08.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Oct 2015 14:08:19 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: X-Original-Sender: Evgeny.Panasyuk@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of evgeny.panasyuk@gmail.com designates 2a00:1450:4010:c04::230 as permitted sender) smtp.mailfrom=evgeny.panasyuk@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:21623 Archived-At: 12.10.2015 22:53, Richard Smith: > > I think you've missed my point about object lifetime. Consider: > > list_monad f(list_monad ints) { > > No matter how you transform this into a class, it won't actually work > (and rightly so): the lifetime of the x object ends the first time line > #2 is reached. When you try to resume at line #1, there's no way to > bring x back to life again. Now, you might suggest that the way to solve > this is to make a copy of the monad state at the point where we hit the > 'await', so you can "safely" resume it multiple times. But that doesn't > work either: your copy's 'r' would refer to the original's 'x' (whose > lifetime has ended), not to the copy's 'x'. Thank you for detailed description, I get your point. I am aware of this issue, and I agree that it can lead to subtle bugs - because such code works in unintuitive/unaccustomed manner. Nevertheless, I don't think that possibility of such bugs makes whole approach non-usable. I think it is acceptable price for performance and generality/features/power it provides. C++ was never a defensive language. For instance I want to use non-owning raw pointers, and I accept the price of increased possibility of memory corruption. And if one needs higher defensiveness - it is possible to use shared/weak_ptr in casual/wasteful manner. Same applies here - I want to copy/move/fork/serialize/etc coroutines, and I agree to pay for possibility of problems with locals lifetime issues. But if someone would like to avoid such issues, and do not need fork/etc - then he could use non-copyable non-movable coroutines allocated on heaps. > > Moreover, C#'s await is implemented based on similar approach: > http://www.codeproject.com/Articles/535635/Async-Await-and-the-Generated-StateMachine > > > The implementation approach is fine for coroutines (C#'s await doesn't > support the list monad / continuations), Yes, C# await doesn't support copy of state (at least in straightforward way). My point here is that approach based on such kind of transformation (coroutine body into method-state-machine, locals to class fields) is already implemented and used in one of mainstream languages. > but doesn't work for the full > generality of monads in a system with mutable state. Why? As I can see copying of coroutine is similar to call/cc, which in turn is somewhat dual to monads. By the way, I did an example sometime ago how to use call/cc to get "monadic flow", including List monad: http://ideone.com/7uOVe2 -- --- 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/. .