220 31257 <312d04a6-8b20-4bf5-8357-507ba9938e84@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: P0534: call/cc, type safety and exceptions Date: Wed, 1 Mar 2017 07:38:12 -0800 (PST) Lines: 153 Approved: news@gmane.org Message-ID: <312d04a6-8b20-4bf5-8357-507ba9938e84@isocpp.org> References: <3a57e294-7254-4358-828d-c9f7757f5295@isocpp.org> <4e6c13b2-4286-4df8-989b-97cbf3bf1cc7@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_10372_935153282.1488382693011" X-Trace: blaine.gmane.org 1488382701 23023 195.159.176.226 (1 Mar 2017 15:38:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Mar 2017 15:38:21 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBZOV3PCQKGQE24IXHCA@isocpp.org Wed Mar 01 16:38:16 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f69.google.com ([74.125.83.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cj6KO-0004uY-VF for gclcip-std-proposals@m.gmane.org; Wed, 01 Mar 2017 16:38:09 +0100 Original-Received: by mail-pg0-f69.google.com with SMTP id 1sf58748689pgz.5 for ; Wed, 01 Mar 2017 07:38:15 -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=j3CfhCg9B2rEwTgmUhv8VOJZ7vWnldjNIW2WFFvdCd4=; b=0QCmd0MTWF/KW4WGX+nTXlLleLedC9LZ/9JlBkJhcbcJZYazcoSuenBngUGJAdJFQd hHMiuPV8hzH2P+PhxG9c5z4BcHSK3Le5MYhO5FeYnfKxsJadD2OkMecOAeH5KFYTGGD/ 8Of4/MTnnL0h1q5YPNNEA9Vi8mwAb/r2yqNCNbdr2ixg9NBZNJuS/1QzuK4gUPZh8t/s O7hl5CPVI9QN0LPxVg+x4E6k3GqHFYiu251Z4X+1PcyuO/lnf8cmaoIiFiUOkLsxuQOa MpOQ/txQCxwt66vvPFcunNBVZrAaNtrbUckvgbobM9XPubFDLKrxgE1ruvS84QklVoUA yc3w== 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=j3CfhCg9B2rEwTgmUhv8VOJZ7vWnldjNIW2WFFvdCd4=; b=YjgzjL1fHj1O8UawdcNEKnwB13JITKVqOF8W52YSEjJ11l4e6VOklR0wt3phj90r5G 653lamNeEU78xUvyPU6amt3W+YJ/xKTjglv6zz2FDQ+2AdVpsOH74w7W+fzP6j8hxG5s Xfnc/bl1sVm+FirOnyj9zaUH0rufX4gX0McmBz9penejmiPSYOjjaMdQQYF6C/ql6QZm wg1+mgnzEI9bMANByLWKXwOR/tJoqe9F5aH1Lahy5vFlQcsIawa6+9gEB6sJWDykFBQU +IdNJYLY6LqiqQhEnlG+6flqiJv02Ci4QXta8zLc2aDKMEDVQ4e9PH0nWHjPbDFwVtpP hMAw== 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=j3CfhCg9B2rEwTgmUhv8VOJZ7vWnldjNIW2WFFvdCd4=; b=Ftona/DKlc8Ht/7wNqKmbFsh3yOUTxM3yqWqGCJsl+9X0bSNqqG7RbPk/YEUWAnG1Q ljbb9KPhokRJMRqmd84unM6A8C75ffhZtfy1qyjdN2GIWEkEhqXgWi1gImm56ZBsjZAe m4CKrXeBHErUOEp2TFeczT5nubSb5AVcXCh5hKr4LgF6jFFSLpYVhbwMrrPzC7nDx0Fa qMtkDC9dS4e12GtWr8FHjQbLH1vmQsOWdpnGaeVRDoP/j9nK5ncbW4yf3fpC+nGYbbmO 6erAmWcD4PwzcEb2/H4afg5l2xm6zOKfU7rVvsPQX6OQsBZVCpr/nXuQPPdjPqm9ZBQD GSXg== X-Gm-Message-State: AMke39nEOsoaeTr4kYjqnSrhOvu37hidTXmeQDBORD6Vq0e9Jjw/DNyWUOkS0xlF4rLaHA== X-Received: by 10.99.114.20 with SMTP id n20mr2830588pgc.97.1488382694733; Wed, 01 Mar 2017 07:38:14 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.12.97 with SMTP id 88ls2944371otr.34.gmail; Wed, 01 Mar 2017 07:38:13 -0800 (PST) X-Received: by 10.157.17.114 with SMTP id p47mr1049997otp.6.1488382693697; Wed, 01 Mar 2017 07:38:13 -0800 (PST) In-Reply-To: <4e6c13b2-4286-4df8-989b-97cbf3bf1cc7@isocpp.org> X-Original-Sender: jmckesson@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:31257 Archived-At: ------=_Part_10372_935153282.1488382693011 Content-Type: multipart/alternative; boundary="----=_Part_10373_438720183.1488382693011" ------=_Part_10373_438720183.1488382693011 Content-Type: text/plain; charset=UTF-8 On Wednesday, March 1, 2017 at 6:39:18 AM UTC-5, Giovanni Piero Deretta wrote: > > On Wednesday, March 1, 2017 at 3:01:25 AM UTC, Nicol Bolas wrote: > >> >> On Tuesday, February 28, 2017 at 9:24:38 PM UTC-5, Oleg Ageev wrote: >>> >>> Hello, >>> >>> I have some questions about call/cc in proposed implementation >>> >>> I think possibility put any arguments in continuation and access to them >>> through template function it is lack of type safety, and isn't good idea to >>> propose it in standard. >>> Why not specialize continuation with type of input and type of output? >>> >> >> Because: >> >> 1) That would limit what you can do with continuations. As currently >> proposed, you can pass different parameters to different parts of >> continuations. Your idea fixes the interface at call/cc time. >> >> 2) P0534 is intended to be as low level as possible while still being >> functional. By specializing types, it would be higher level than strictly >> *necessary*. >> > > FWIW, I strongly disagree. Getting continuation correctly typed is > important and any help the compiler can give when using such a mind-bending > construct as a continuation is very welcome. In particular getting the > typing of something like invoke_on_top is non trivial (it certainly took me > a few tries). > A type-safe version of the data passing API is important and should be shipped with this system. The reason being that the system can implement it more efficiently than the user can. For example, the current system could gain reasonable type safety by passing everything via `std::any`. However, doing so brings with it some baggage. `any` can only be used with copyable types, which is an unnecessary restriction for our needs. If the `T` is somewhat large, `any` will dynamically allocate memory for it, whereas the unsafe API always uses the continuation's stack for the object. Now of course, one can implement safe typing by wrapping `callcc` and `continuation` by implementing the guts of an `any`. Essentially, each numbered parameter would be 2 actual parameters: the value itself and its `type_index`. And when you cast it back, if the index you ask for doesn't match the one used by the parameter, an exception is thrown or whatever. The problem is, as always with low-level tools, inter-operability. If you don't provide higher-level tools at the same time as lower-level ones, you encourage fragmentation. My `safe_callcc/safe_continuation` can't work with someone else's `safe_callcc/safe_continuation`, even if they're doing the same thing. So we need the safe mechanism, and we need it shipped with the system. But that should not be the *only* way; the lower-level form should still exist. Now, maybe the type-safe version should be the *default*, so that if you want the lower-level, unsafe API, we can clearly see that safety is being sacrificed. So `callcc/continuation` would naturally be type-safe, with `unsafe_callcc/unsafe_continuation` being not type safe. -- 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/312d04a6-8b20-4bf5-8357-507ba9938e84%40isocpp.org. ------=_Part_10373_438720183.1488382693011 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, March 1, 2017 at 6:39:18 AM UTC-5, Giovanni = Piero Deretta wrote:
On Wednesday, March 1, 2017 at 3:01:25 AM UTC, Nicol Bolas wrote:<= br>

On Tuesday,= February 28, 2017 at 9:24:38 PM UTC-5, Oleg Ageev wrote:
Hello,

I have some questions= about call/cc in proposed implementation

I think possibility put an= y arguments in continuation and access to them through template function it= is lack of type safety, and isn't good idea to propose it in standard.=
Why not specialize continuation with type of input and type of output?<= br>

Because:

1) That would limit what you= can do with continuations. As currently proposed, you can pass different p= arameters to different parts of continuations. Your idea fixes the interfac= e at call/cc time.

2) P0534 is intended to be as low level as possib= le while still being functional. By specializing types, it would be higher = level than strictly necessary.

= FWIW, I strongly disagree. Getting continuation correctly typed is importan= t and any help the compiler can give when using such a mind-bending constru= ct as a continuation is very welcome. In particular getting the typing of s= omething like invoke_on_top is non trivial (it certainly took me a few trie= s).

A type-safe version of the data pa= ssing API is important and should be shipped with this system. The reason b= eing that the system can implement it more efficiently than the user can.
For example, the current system could gain reasonable type safety by = passing everything via `std::any`. However, doing so brings with it some ba= ggage. `any` can only be used with copyable types, which is an unnecessary = restriction for our needs. If the `T` is somewhat large, `any` will dynamic= ally allocate memory for it, whereas the unsafe API always uses the continu= ation's stack for the object.

Now of course, one can implement s= afe typing by wrapping `callcc` and `continuation` by implementing the guts= of an `any`. Essentially, each numbered parameter would be 2 actual parame= ters: the value itself and its `type_index`. And when you cast it back, if = the index you ask for doesn't match the one used by the parameter, an e= xception is thrown or whatever.

The problem is, as always with low-l= evel tools, inter-operability. If you don't provide higher-level tools = at the same time as lower-level ones, you encourage fragmentation. My `safe= _callcc/safe_continuation` can't work with someone else's `safe_cal= lcc/safe_continuation`, even if they're doing the same thing.

So= we need the safe mechanism, and we need it shipped with the system. But th= at should not be the only way; the lower-level form should still exi= st.

Now, maybe the type-safe version should be the default, s= o that if you want the lower-level, unsafe API, we can clearly see that saf= ety is being sacrificed. So `callcc/continuation` would naturally be type-s= afe, with `unsafe_callcc/unsafe_continuation` being not type safe.

--
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/312d04a6-8b20-4bf5-8357-507ba9938e84= %40isocpp.org.
------=_Part_10373_438720183.1488382693011-- ------=_Part_10372_935153282.1488382693011-- .