220 31306 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:11:07 -0800 (PST) Lines: 275 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_153_1034785371.1488449467845" X-Trace: blaine.gmane.org 1488449472 21628 195.159.176.226 (2 Mar 2017 10:11:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 2 Mar 2017 10:11:12 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDEP3I7TGEILZX67YUCRUBBRTWAS4@isocpp.org Thu Mar 02 11:11:06 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f70.google.com ([74.125.83.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cjNhP-0004uo-G8 for gclcip-std-proposals@m.gmane.org; Thu, 02 Mar 2017 11:11:03 +0100 Original-Received: by mail-pg0-f70.google.com with SMTP id d18sf86749274pgh.2 for ; Thu, 02 Mar 2017 02:11:10 -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=z7p5Fbdv/2NUxhb7wbn2CY7foZNs8jNHkd65RLMShJU=; b=1NKqTN167KIBkiEId0MDjdvT61rS/qyVI0ICuN1VNjSQlYvQRlEUJ8rCjLntGaJaeg ip796gebt5esZOcKqS3dXTOqOmgkiGlmknb9+abIzg8TOIBCsVctKGFe/ACojo+aX9PN aeqNSZcvAaiN1Oo3dqFXMBsoOoaxWshsoexQ2Fc0n7PNV+YSjwGexhvjDscTcfxcnVWe JuLsFUmW9l16ObZP+rJ+FPBJ231qTbCVbqpTtZOvvpxrmcvepnSVqAZtTlO3/WH/kYbX AJjAOzwyPQrzRL/XYmyVI/GOeQPVA29/+tJM2tsy9l2cTOLn0U/1AM1I6LDtWAxA2f9r 0Czw== 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=z7p5Fbdv/2NUxhb7wbn2CY7foZNs8jNHkd65RLMShJU=; b=mISERnaKWAMAb5OfLFggUHrxn8fwEK+XJfUPdKHiqGIfmu7A3Do8STbFFDAZ4XVGDV HS+3kwJpPCU5+O3xnDOrxJsNlB52WQh6y5s3nnC+525fKzDKZTfv/8VdjslNRd/rnGq/ khOvuOur3OjdryCKIazOy468DWgvGueIs+ib5TprVV1GVzuQdNgPfuwQl9VBIo8P8QgP dAfDnpbWUmZ53yEXfOmYn7gONLnPj9eawy7vUoOo5aySQAno3mh6SjIWvTbjKgd83ibR QqjjxOAyrH5HjnzwL2Ow5Rzfis1c3bMmJ+97SH7vLcGu30h2rG/nuLdbmWHAHRr4MiBO 08pg== 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=z7p5Fbdv/2NUxhb7wbn2CY7foZNs8jNHkd65RLMShJU=; b=E51Hv3Ug2aipXTeSFpm4IaWGm2vq5rainAx2VVXY4l1DmorMaIIuglOae6j191lhLy 3/WzXQBHvJdF+0bfbWRyU0T6HtKphJ0n8JMEUKfgOEEhB79aulWJPdXNSWYhoeCijlzV FF2HNyHoNu7wdzQcwRYA7b3zWW94ToLZY0L5Iimw+6ZKgZv8gnA2dzekc5N8f0kRQVFN rhP/y1MCHzIIAxJ6qBWJLtF9NhgvfH9q68kEdcSTYcdT1tx1lcMdN+UcQTM4pcDov7yZ MFECMnYoL3cTLgkTrcCfvoG2sxpMbOYA0dYT07DN3Me4wTqUzbyn5/atEbNd9lLmkDSW qNnw== X-Gm-Message-State: AMke39luCbPKsBzwrmhQK3EiNd4tNNfJYnk+68jsmT+AH4EKbbjht+dnqXC7Ypzi3CM6wQ== X-Received: by 10.98.76.199 with SMTP id e68mr2753934pfj.19.1488449469346; Thu, 02 Mar 2017 02:11:09 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.88.40 with SMTP id r40ls4428096oth.13.gmail; Thu, 02 Mar 2017 02:11:08 -0800 (PST) X-Received: by 10.157.56.117 with SMTP id r50mr1501984otd.12.1488449468538; Thu, 02 Mar 2017 02:11:08 -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:31306 Archived-At: ------=_Part_153_1034785371.1488449467845 Content-Type: multipart/alternative; boundary="----=_Part_154_2084467805.1488449467845" ------=_Part_154_2084467805.1488449467845 Content-Type: text/plain; charset=UTF-8 On Thursday, March 2, 2017 at 9:43:30 AM UTC, Bengt Gustafsson wrote: > > Hi. > > I do really like the general idea of callcc and continuation class. But I > don't understand the need of data transfer at this low abstraction level. > You can of course arrange to have both sides of the continuation share a memory location, but it is cumbersome (especially when the two sides can switch freely like with symmetric coroutines) and potentially inefficient (The parameter passing can be made literally free in the low level assembler switching function by simply not saving and restoring a specific register). The implementation will need to pass parameters through anyway (to implement execute_on_top or exception transport, so it makes sense to expose the functionality to the user. Although I would prefer the functionality to be properly typed, I would settle for a single void* parameter as typing can be implemented on top of it with no cost. > After all, these are not threads, so there is no asynchronism to think > about. To prove this point I implemented the classical generator pattern > without using continuation's data transfer possibilities (see attached > file). Sure enough, when the generator lambda calls yield(value) it stops > processing until the main program calls operator++ again. So all this time > the parameter to yield is valid on the generator's stack and available by > reference to the main program. So while there are obviously needs to send > data both ways for different patterns I fail to see why it must be a > feature of the lowest level abstraction. > well, yes the functionality is normally implemented by simply passing to the next continuation a pointer to the parameter on the stack. > > When I wrote the code for generator.h I also saw that the pattern > `mContinuation = mContinuation()` seems to be mandatory. If you forget the > assignment you loose the ability to continue the next time. While there may > be cases where you want to assign the continuation returned from operator() > to some other std::continuation object, wouldn't it be more appropriate to > make simple things simple by letting operator() return void and > automatically update its `this` to the new state before returning and then > applications which really do need to move the continuation object elsewhere > can do so afterwards. Again there are no threading issues so it should be > safe. In the back of my head I think there is some exception safety issue > at play here, but if so it needs to be explained more clearly. > My own implementation updates this, but I don't have a strong opinion, and the explicit assignment makes it more obvious that the new continuation has potentially no relation to the one just consumed. > > A comment on the invoke_on_top_t functionality. Why add a special tag type > just to be able to overload operator() to do another task when there is the > possibility to add a regular method: > std::continuation::invoke_on_top(args...). > A possibility is dropping operator() and using callcc for everything. The full callcc signature woud be like this: callcc(cont, fn, arg) Which is the same as cont(invoke_on_top, fn, args) A new continuation can be created with: callcc(make_empty_continuation(), fn, arg) (where make_empty_continuation just creates a continuation that will exit immediately upon invocation) Switching is just: callcc(cont, identity, arg); This closely mimics callcc behaviour in other languages. In fact make_empty_continuation() and callcc are really the only two primitives you need. Of course overloads and default parameters would make use of the library more straightforward (and, in the case of context switching, more efficient). Also it would be interesting to know when this rather strange functionality > is useful. > The functionality is actually not strange at all if you think of the underlying CPS transformation, and it simplifies the implementation of continuation itself, as it can be directly used to implement continuation creation (just invoke on top of an empty continuation), exit (invoke on top of next and cleanup source), exception throwing (invoke on top then throw). It also greatly simplifies more complex uses of continuation (handy to implement scheduling, waiting, etc). > An issue I stumbled upon during implementation was not being able to do > callcc() on a method. I think an overload of callcc specifically for method > pointers (in parallel with the std::function constructor set) will be > needed. This is as the std::continuation&& parameter gets prepended to the > args of callcc when calling the provided function. If the provided function > is a std::function wrapping a method pointer its operator() will expect to > get the 'this' of the object to call and instead it will get the > std::continuation prepended by callcc! > > // Example: > > class MyClass { > void fun(std::continuation&& cont); > }; > > MyClass myObj; > > callcc(&MyClass::fun, myObj); // This is what you want to write, but > callcc does not take method pointers. > > // So you may try this: > > callcc(std::function(&MyClass::fun), > myObj); // Mismatched types as callcc gets the order wrong. > > // Instead you have to conjure up a lambda: > > callcc([&](std::continuation&& cont) { myObj.fun(std::move(cont); }); > > > > While the lambda solution works I think it is quite weak not to allow the > first version. > > I think a fully fledged implementation would have full INVOKE like semantics, but as it is very straightforward, probably implementing the feature is not very high in Oliver's priorities. -- 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/a3cae110-2522-4364-9354-d9d87037b012%40isocpp.org. ------=_Part_154_2084467805.1488449467845 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thursday, March 2, 2017 at 9:43:30 AM UTC, Bengt Gustaf= sson wrote:
Hi= ..

I do really like the general idea of callcc and contin= uation class. But I don't understand the need of data transfer at this = low abstraction level.

You can of course a= rrange to have both sides of the continuation share a memory location, but = it is cumbersome (especially when the two sides can switch freely like with= symmetric coroutines) and potentially inefficient (The parameter passing c= an be made literally free in the low level assembler switching function by = simply not saving and restoring a specific register). The implementation wi= ll need to pass parameters through anyway (to implement execute_on_top or e= xception transport, so it makes sense to expose the functionality to the us= er. Although I would prefer the functionality to be properly typed, I would= settle for a single void* parameter as typing can be implemented on top of= it with no cost.

=C2=A0
After all, these are not threads, so there is= no asynchronism to think about. To prove this point I implemented the clas= sical generator pattern without using continuation's data transfer poss= ibilities (see attached file). Sure enough, when the generator lambda calls= yield(value) it stops processing until the main program calls operator++ a= gain. So all this time the parameter to yield is valid on the generator'= ;s stack and available by reference to the main program. So while there are= obviously needs to send data both ways for different patterns I fail to se= e why it must be a feature of the lowest level abstraction.

well, yes the functionality is normally implemented by si= mply passing to the next continuation a pointer to the parameter on the sta= ck.
=C2=A0

When I wrote the code for generator.h I also saw = that the pattern `mContinuation =3D mContinuation()` seems to be mandatory.= If you forget the assignment you loose the ability to continue the next ti= me. While there may be cases where you want to assign the continuation retu= rned from operator() to some other std::continuation object, wouldn't i= t be more appropriate to make simple things simple by letting operator() re= turn void and automatically update its `this` to the new state before retur= ning and then applications which really do need to move the continuation ob= ject elsewhere can do so afterwards. Again there are no threading issues so= it should be safe. In the back of my head I think there is some exception = safety issue at play here, but if so it needs to be explained more clearly.=

My own implementation updates this, but I= don't have a strong opinion, and the explicit assignment makes it more= obvious that the new continuation has potentially no relation to the one j= ust consumed.
=C2=A0
<= div dir=3D"ltr">

A comment on the invoke_on_top_t functi= onality. Why add a special tag type just to be able to overload operator() = to do another task when there is the possibility to add a regular method: s= td::continuation::invoke_on_top(args...).

A possibility is dropping operator() and using callcc for everything.= The full callcc signature woud be like this:

=C2=A0=C2=A0 callcc(co= nt, fn, arg)

Which is the same as cont(invoke_on_top, fn, args)
=
A new continuation can be created with:

=C2=A0 callcc(make_empty= _continuation(), fn, arg)

(where make_empty_continuation just create= s a continuation that will exit immediately upon invocation)
Switching i= s just:

=C2=A0 callcc(cont, identity, arg);

This closely mimi= cs callcc behaviour in other languages. In fact make_empty_continuation() a= nd callcc are really the only two primitives you need.

Of course ove= rloads and default parameters would make use of the library more straightfo= rward (and, in the case of context switching, more efficient).

Also it= would be interesting to know when this rather strange functionality is use= ful.

The functionality is actually not str= ange at all if you think of the underlying CPS transformation, and it simpl= ifies the implementation of continuation itself, as it can be directly used= to implement continuation creation (just invoke on top of an empty continu= ation), exit (invoke on top of next and cleanup source), exception throwing= (invoke on top then throw). It also greatly simplifies more complex uses o= f continuation (handy to implement scheduling, waiting, etc).
=C2=A0
=
An issue I stumbled upon during implementation was not being able to d= o callcc() on a method. I think an overload of callcc specifically for meth= od pointers (in parallel with the std::function constructor set) will be ne= eded. This is as the std::continuation&& parameter gets prepended t= o the args of callcc when calling the provided function. If the provided fu= nction is a std::function wrapping a method pointer its operator() will exp= ect to get the 'this' of the object to call and instead it will get= the std::continuation prepended by callcc!

// Example:
=

class MyClass {
=C2=A0 =C2=A0 void fun(std::c= ontinuation&& cont);
};

MyClass = myObj;

callcc(&MyClass::fun, myObj); =C2=A0 = =C2=A0// This is what you want to write, but callcc does not take method po= inters.

// So you may try this:

callcc(std::function<void(MyClass&, std::continuation&am= p;&)>(&MyClass::fun), myObj); =C2=A0 // Mismatched types as= callcc gets the order wrong.

// Instead you have = to conjure up a lambda:

callcc([&](std::contin= uation&& cont) { myObj.fun(std::move(cont); });
<= div>

While the lambda solution works I think i= t is quite weak not to allow the first version.

<= /blockquote>
I think a fully fledged implementation would have full INV= OKE like semantics, but as it is very straightforward, probably implementin= g the feature is not very high in Oliver's priorities.
=C2=A0
<= /div>

--
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/a3cae110-2522-4364-9354-d9d87037b012= %40isocpp.org.
------=_Part_154_2084467805.1488449467845-- ------=_Part_153_1034785371.1488449467845-- .