220 31227 article Path: news.gmane.org!.POSTED!not-for-mail From: Oliver Kowalke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: P0534: call/cc, type safety and exceptions Date: Wed, 1 Mar 2017 08:26:35 +0100 Lines: 124 Approved: news@gmane.org Message-ID: References: <3a57e294-7254-4358-828d-c9f7757f5295@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11490382b78e270549a63c55 X-Trace: blaine.gmane.org 1488353217 16517 195.159.176.226 (1 Mar 2017 07:26:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Mar 2017 07:26:57 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCLZHP5J7MHRBQHP3HCQKGQEOAITEFA@isocpp.org Wed Mar 01 08:26:51 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f69.google.com ([209.85.218.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ciyex-0003il-5L for gclcip-std-proposals@m.gmane.org; Wed, 01 Mar 2017 08:26:51 +0100 Original-Received: by mail-oi0-f69.google.com with SMTP id q127sf28215885oih.1 for ; Tue, 28 Feb 2017 23:26:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :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=blFopgH7DKHcHm8dz9c3uXanSl27rHsWNBoQSRRPZnk=; b=N7av1L1X3zqaet9x+7nETk0q1zihLy5pk3I+yHr01K47C1Ifsgs5toJBnOAFMX3VSz 33vFx6pxvWyQl4lWPI9cDbHVw7jcJG6RpuXbMSY8wOVqD8MdkH2Ff6M4obdZJ3U6PKk+ ay2oNh9/Ie4HTstxBz/uveu0JkVvEMokTpD/A0khHf3d9MZ5ZGIhjU7DdcU85Yefj6hv ogO7KxwC14okGkmgW4zFv+daS/xbOhAcYsAq6rahUcrD197aM9l5wow7Xy9pZeql6GjT UB9F2lWghnTPcprpggJ+7z+sKAlslrfOXOhgOYAENObefFwMdpdzyD94UY+4XosHwQh2 uRKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to: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=blFopgH7DKHcHm8dz9c3uXanSl27rHsWNBoQSRRPZnk=; b=hr9NdS+5DH3V0desNxJESlv8sZy5iBPwqS7YcPYD+LXh7ZWiH/WXrZf+jv8SPDVMXd S4LcCuvhdCpIv0q04xPPukGedFTdYYJ1phMZmfsvWPDiaKjDs8PpRO8HcBVFKK6tYurX oK9awz47KA+oWdWstNVOjnHjokgnQLB0EVGxp8oPOt4TBdzqaqCqFNpA+kh3WgsgT5nC sztuGsD431U6Mf/6f7wevMZjjyfRDDqVifx3NucGXgKFVY/9EcpqIMireuCS8OxIGlm2 OjEC/8QAb7GuBJmkIjggM5L+ljMIviNUoENsLuDm+8aoT8EJefjrVI0klawRk29pwQh6 CLDw== X-Gm-Message-State: AMke39mX1R4zQ78dndwPmdCOISAyvWS39FQIWcw4VYi56+TP3rpJU40mqldQZ1EAW+iLyw== X-Received: by 10.157.21.37 with SMTP id u34mr2186153otf.40.1488353216911; Tue, 28 Feb 2017 23:26:56 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.61.70 with SMTP id a64ls3273557otc.35.gmail; Tue, 28 Feb 2017 23:26:56 -0800 (PST) X-Received: by 10.13.206.5 with SMTP id q5mr2000382ywd.225.1488353216096; Tue, 28 Feb 2017 23:26:56 -0800 (PST) Original-Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com. [2607:f8b0:4002:c05::236]) by mx.google.com with ESMTPS id e185si371341ybe.103.2017.02.28.23.26.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Feb 2017 23:26:56 -0800 (PST) Received-SPF: pass (google.com: domain of oliver.kowalke@gmail.com designates 2607:f8b0:4002:c05::236 as permitted sender) client-ip=2607:f8b0:4002:c05::236; Original-Received: by mail-yw0-x236.google.com with SMTP id d1so25473011ywd.2 for ; Tue, 28 Feb 2017 23:26:56 -0800 (PST) X-Received: by 10.129.119.130 with SMTP id s124mr1982584ywc.202.1488353215612; Tue, 28 Feb 2017 23:26:55 -0800 (PST) Original-Received: by 10.129.173.21 with HTTP; Tue, 28 Feb 2017 23:26:35 -0800 (PST) In-Reply-To: <3a57e294-7254-4358-828d-c9f7757f5295@isocpp.org> X-Original-Sender: oliver.kowalke@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of oliver.kowalke@gmail.com designates 2607:f8b0:4002:c05::236 as permitted sender) smtp.mailfrom=oliver.kowalke@gmail.com; dmarc=pass (p=NONE sp=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-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:31227 Archived-At: --001a11490382b78e270549a63c55 Content-Type: text/plain; charset=UTF-8 2017-03-01 4:01 GMT+01:00 Nicol Bolas : > > > 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. > For instance during the implementation of my coroutine and fiber libraries I encountered that initialization- and termination-phases were required. In those phases no data at all or data of different types are transferred. Imagine the type of the transferred data does not have an default-ctor - you have to pass an value each time the continuation is resumed. What if you can't produce one or you want to terminate the continuation. Of course you could use something like variant or optional, but you would pay each time for the overhead even in cases were you don't need variant/optional etc. I've had several implementations of call/cc - the one presented in P0534 seams to me the most suitable. > 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*. > right , that's one of the ideas behind P0534 > We can catch exception in `run` function of `record` and rethrow in `context_exit` The switch mechanism proposed in P0534 is symmetric, e.g you have to explicitly specify the continuation that has to resumed next. To which continuation do you want to jump to in context_exit? -- 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/CA%2Bwfc19mghDOW62NTTtiy%3D2GBwcwCtuBCX9zQWx7qYEuCsQJEw%40mail.gmail.com. --001a11490382b78e270549a63c55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2017= -03-01 4:01 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:


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

I have some questions about call/cc in proposed impleme= ntation

I think possibility put any arguments in continuation and ac= cess to them through template function it is lack of type safety, and isn&#= 39;t good idea to propose it in standard.
Why not specialize continuatio= n 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 part= s of continuations. Your idea fixes the interface at call/cc time.

For instance during the implementat= ion of my c= oroutine and fiber libraries I encountered that initialization- and = termination-phases were required. In those phases no data at all or data of= different types are transferred.
Imagine the type of the tra= nsferred data does not have an default-ctor - you have to pass an value each ti= me the continuation is resumed. What if you can't produce one or you wa= nt to terminate the continuation.
Of course you could use somethi= ng like variant or optional, but you would pay each time for the overhead e= ven in cases were you don't need variant/optional etc.

I&= #39;ve had several implementations of call/cc - the one=C2=A0 presented in = P0534 seams to me the most suitable.

=C2=A0
2) P0534 is= intended to be as low level as possible while still being functional. By s= pecializing types, it would be higher level than strictly necessary.=

right , that's one of = the ideas behind P0534

> We can catch exception in `run` function= of `record` and rethrow in `context_exit`

The switch mec= hanism proposed in P0534 is symmetric, e.g you have to explicitly specify t= he continuation that has to resumed next.
To which continuati= on do you want to jump to in context_exit?

--
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/CA%2Bwfc19mgh= DOW62NTTtiy%3D2GBwcwCtuBCX9zQWx7qYEuCsQJEw%40mail.gmail.com.
--001a11490382b78e270549a63c55-- .