220 31307 article Path: news.gmane.org!.POSTED!not-for-mail From: Giovanni Piero Deretta Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: P0534: call/cc, type safety and exceptions Date: Thu, 2 Mar 2017 02:52:43 -0800 (PST) Lines: 145 Approved: news@gmane.org Message-ID: References: <3a57e294-7254-4358-828d-c9f7757f5295@isocpp.org> <4e6c13b2-4286-4df8-989b-97cbf3bf1cc7@isocpp.org> <312d04a6-8b20-4bf5-8357-507ba9938e84@isocpp.org> <762243ed-0c31-461d-b6fd-fdb8759857b2@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_167_1370632866.1488451963542" X-Trace: blaine.gmane.org 1488451964 23412 195.159.176.226 (2 Mar 2017 10:52:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 2 Mar 2017 10:52:44 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDEP3I7TGEIPZ4W7YUCRUBHQD4BEM@isocpp.org Thu Mar 02 11:52:39 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f198.google.com ([209.85.161.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cjOLf-0005g4-DW for gclcip-std-proposals@m.gmane.org; Thu, 02 Mar 2017 11:52:39 +0100 Original-Received: by mail-yw0-f198.google.com with SMTP id j3sf65300275ywj.5 for ; Thu, 02 Mar 2017 02:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :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=i+9lNwQ0/OCuyLnd1oGRWy1O9dhUZkoJZcm+DjkaHJk=; b=CerwjtnWaIA0J3HVVMU0CVaRUK7MUJTvPlCVqP0MIBnPK7Q9zWslTI8HIuuCRiJfem 04O12UvLA5ezhZyibDimjq7nmC8tyv/Q5uL1MhknW/xNW7niF1LnZxND7WeCkR+MYbSh r8LXn7fbQCyBcjbHvi80u5bDT9clsMpN7cjuWkRpGV6x9Kdpj/HCld24xIPVVZCTPwDY iL/tUv/6iXJVj0iB7cy15hGagZd+l2r1nrNHqGBZ6sZH3Czk9DMqfiE+8advElUO43h8 vSsxkRrLdHwcXF86msseEFgy3GwjeAT3Opr7fkNRG+myXVCS1uT2uyTjpdldkNtcU+KG G0/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :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=i+9lNwQ0/OCuyLnd1oGRWy1O9dhUZkoJZcm+DjkaHJk=; b=K5J3S6Iwn93IIf3VpwkpllXIaFvG31ZDTaXmj1x+MgFODt0GLBRIOTSowMY3nSfAdR N8/OLCYNPu0FxGrnyhkVChH4S2mlflmU4X4ymYjR+nD0XKgoVC16dJVlboMybgqYGvlH zS2unPS8DbQMmAB8xzc4rjzyC8KLgMq5t71UYSqtBZz+dfUVCm9kGKomtPvs0OpdaA0M vKrTI5J+JfptjS+soNj5V02FgKxhXXq8d8Xw3SBTqZ5iuDKNrUm7el7P6O/8eUNVgNrk IyCBzRO85St/w8u+rfrStaO3IPx87jkOsBINtj+j+PWWwYacqjHJH3ztJOJKHRs0b2on yMyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=i+9lNwQ0/OCuyLnd1oGRWy1O9dhUZkoJZcm+DjkaHJk=; b=dMiCrtVAGDeQ63LZYKhVa1rEz3ixHS5sKHjUwOpTbLqpJmbjM+LPGBAq23sSGNlJA/ 7Lrqi86uKcUVIeF1Oa1M7Hlc2L3kyxs8iB8zq7dcgQaAXuBMR0UxwEmmNj6XEijx6rXw Td5z8iV6qwpaL5xRk4XjOzyBc5vxGBk6/XExGZicIWn7HqWyVbUYFU9eWAHaCNsirpc6 9Fu950EZyAGsV9gssWpC/RcrGe7vpPBdNDINmAfJJkmCjzDHqFQX96QWbyQff0dzdLhX eLV1ZIqn4s/dOCel/ps8QiRtLd00WpPYtzo/bF4D/pfYvjS6MBQ6U/LVputvZ1INhrAr JrHg== X-Gm-Message-State: AMke39nbhn5kUQt0NddRqvdA7dPfuQhv/rqpA/GGYpuDThvM4+Es68e5ohli9dVB/0cJqw== X-Received: by 10.13.221.140 with SMTP id g134mr5047299ywe.55.1488451965221; Thu, 02 Mar 2017 02:52:45 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.68.202 with SMTP id p10ls3226582otg.18.gmail; Thu, 02 Mar 2017 02:52:44 -0800 (PST) X-Received: by 10.157.16.48 with SMTP id h45mr1514161ote.10.1488451964381; Thu, 02 Mar 2017 02:52:44 -0800 (PST) In-Reply-To: X-Original-Sender: gpderetta@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:31307 Archived-At: ------=_Part_167_1370632866.1488451963542 Content-Type: multipart/alternative; boundary="----=_Part_168_825494097.1488451963542" ------=_Part_168_825494097.1488451963542 Content-Type: text/plain; charset=UTF-8 On Wednesday, March 1, 2017 at 8:22:01 PM UTC, Nicol Bolas wrote: > > [...] > > Static checking between the parameters to `callcc` and the parameters to > the function being invoked is one thing. But static checking between the > parameters to `continuation::operator()` and to the receiving code is quite > something else. It is perfectly reasonable to initiate a `callcc` with one > set of parameters, but provide different parameters of different types at > continuation time. > > > Also, it's important to recognize that the function which began the > `callcc` operation may be doing generic boilerplate stuff: storing a > promise, building a channel, etc. Its return value will in many cases be > irrelevant. So it doesn't make sense to have `callcc` statically assume > that the return value of that function is meaningful to the caller. > You are taking my parallel to std::funciton too literally. There is no expectation that the parameters passed to the function object on context creation to match the continuation return and receive type (and the function object must always return a continuation, so there is no freedom there). My request is that the continuation encodes the types of the parameter passed through and received from and enforce it statically, the same way that std::function enforces them. > > The fundamental difference between `std::function` and a continuation is > that the former is intended to be a go-between and the latter is not. > It very much is. it is a communication channel between two arbitrary thread of executions. In fact delimited continuations [1] are really indistinguishable from functions from the outside, but that's beside the point. > The former is just a value type for storing and invoking any C++ callable. > `callcc` has nothing to do with that; it's creating new functionality. And > that new functionality has its own needs. > > For example, guaranteed elision should still work through a > `std::function` call, for both parameters and return values. But there's no > way to make it work through a continuation; there has to be a copy/move of > parameters into the continuation's stack, and a copy/move of return values > from the continuation's stack. > Apart from the fact that cross coroutine parameter copy elision is very much feasible with compiler help, you are taking the parallel too literally. [1] contrary to what P0534 claims, it describes delimited continuations; I'm not even sure you can have undelimited continuations when you have one-shot semantics. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f67a3b9d-3fec-40c5-95a2-576acf88b6f9%40isocpp.org. ------=_Part_168_825494097.1488451963542 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, March 1, 2017 at 8:22:01 PM UTC, Nicol Bolas= wrote:
[...]<= /div>
=C2=A0
Static checking between the parameters to `callcc` and the param= eters to the function being invoked is one thing. But static checking betwe= en the parameters to `continuation::operator()` and to the receiving code i= s quite something else. It is perfectly reasonable to initiate a `callcc` w= ith one set of parameters, but provide different parameters of different ty= pes at continuation time.
=C2=A0

Also, it's important = to recognize that the function which began the `callcc` operation may be do= ing generic boilerplate stuff: storing a promise, building a channel, etc. = Its return value will in many cases be irrelevant. So it doesn't make s= ense to have `callcc` statically assume that the return value of that funct= ion is meaningful to the caller.

You a= re taking my parallel to std::funciton too literally.=C2=A0 There is no exp= ectation that the parameters passed to the function object on context creat= ion to match the continuation return and receive type (and the function obj= ect must always return a continuation, so there is no freedom there). My re= quest is that the continuation encodes the types of the parameter passed th= rough and received from and enforce it statically, the same way that std::f= unction enforces them.
=C2=A0

The fundamental difference between `std::= function` and a continuation is that the former is intended to be a go-betw= een and the latter is not.

It very much i= s. it is a communication channel between two arbitrary thread of executions= .. In fact delimited continuations [1] are really indistinguishable from fun= ctions from the outside, but that's beside the point.
=C2=A0
The former= is just a value type for storing and invoking any C++ callable. `callcc` h= as nothing to do with that; it's creating new functionality. And that n= ew functionality has its own needs.

For example, guaranteed elision = should still work through a `std::function` call, for both parameters and r= eturn values. But there's no way to make it work through a continuation= ; there has to be a copy/move of parameters into the continuation's sta= ck, and a copy/move of return values from the continuation's stack.
=

Apart from the fact that cross coroutine = parameter copy elision is very much feasible with compiler help, you are ta= king the parallel too literally.

[1] contrary to what P05= 34 claims, it describes delimited continuations; I'm not even sure you = can have undelimited continuations when you have one-shot semantics.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/f67a3b9d-3fec-40c5-95a2-576acf88b6f9= %40isocpp.org.
------=_Part_168_825494097.1488451963542-- ------=_Part_167_1370632866.1488451963542-- .