220 10812 <5381BCA6.3060803@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: N4015: A proposal to add a utility class to represent expected monad Date: Sun, 25 May 2014 11:49:26 +0200 Lines: 331 Approved: news@gmane.org Message-ID: <5381BCA6.3060803@wanadoo.fr> References: <94ded66f-1c50-47b9-8a04-b83805443da9@isocpp.org> <5380804B.80607@wanadoo.fr> <0e4dbb0e-0a7e-4164-be4e-60e114b18548@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000306040301030003010009" X-Trace: ger.gmane.org 1401011379 21177 80.91.229.3 (25 May 2014 09:49:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 May 2014 09:49:39 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBKHZQ2OAKGQE3MTR4VI@isocpp.org Sun May 25 11:49:32 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f198.google.com ([209.85.212.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WoV3a-0001Pb-D9 for gclcip-std-proposals@m.gmane.org; Sun, 25 May 2014 11:49:30 +0200 Original-Received: by mail-wi0-f198.google.com with SMTP id f8sf1412894wiw.1 for ; Sun, 25 May 2014 02:49:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=4cSAt5Nh8PZuAmIkkzjcKTBLInYwLdGxH6I7hMCYCIA=; b=QdWsNapowGigRoEk3dXOu85iQJRd47/+TrNZ94PejPaxBRSL9c4DkSPsw3q8z+Sk94 nYHXvlLIz0fnAtnM7GJBYMhnDRZdTL0YiJVNBBAwkypVyGLI1SBaFB9V1Gg6EURv5oaO c1P6hyt6ZRYEMoHJcsL/prJRsPezyU0zW2+uvPu4j2u+AZsDksEpNoFkDaVm0sf6fI3E JcBUle3Lc027lmtcxjI1slWam8b164zytt7rALrMgbLvChDFrfygkYkExQrDEwC+7LwK u9KHFcC6tSYmoLT0H6LUkzIB5Fwyl3uEqIxQJHmYLjUWY0jp0UVD4CwcPmONy1/G5Et9 Jtxg== X-Gm-Message-State: ALoCoQkGb+MC9nYfJFq2wHY26fFHqh4ntgkieHFbRxgJHMmTk2g8OaFBowr6cANsqbEPZfhbSBU1 X-Received: by 10.112.136.229 with SMTP id qd5mr40691lbb.21.1401011369810; Sun, 25 May 2014 02:49:29 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.109.73 with SMTP id hq9ls278694wib.5.canary; Sun, 25 May 2014 02:49:27 -0700 (PDT) X-Received: by 10.180.85.10 with SMTP id d10mr23243211wiz.0.1401011367892; Sun, 25 May 2014 02:49:27 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr. [80.12.242.130]) by mx.google.com with ESMTP id gq7si10480516wib.55.2014.05.25.02.49.27 for ; Sun, 25 May 2014 02:49:27 -0700 (PDT) Received-SPF: none (google.com: vicente.botet@wanadoo.fr does not designate permitted sender hosts) client-ip=80.12.242.130; Original-Received: from new-host.home ([92.139.162.34]) by mwinf5d16 with ME id 69pS1o00N0kqAWs039pTDk; Sun, 25 May 2014 11:49:27 +0200 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Sun, 25 May 2014 11:49:27 +0200 X-ME-IP: 92.139.162.34 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: <0e4dbb0e-0a7e-4164-be4e-60e114b18548@isocpp.org> X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: vicente.botet@wanadoo.fr does not designate permitted sender hosts) smtp.mail=vicente.botet@wanadoo.fr 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:10812 Archived-At: This is a multi-part message in MIME format. --------------000306040301030003010009 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 24/05/14 17:58, Ivan =C4=8Cuki=C4=87 a =C3=A9crit : > I guess you have considered a lot of different options. > > Is there a publicly accessible log of the discussions? Otherwise I=20 > have no choice but to bother you with more questions. :) > > in [1] ErrorT is a n error monad transformer that takes an error e > and another monad m. expected doesn't takes an error type and a > monad, but a type. > > > Yes, but I hope you got my point regarding the naming. I'd rather that=20 > the api caters to the "happy path" (to quote E. Meijer) than to the=20 > failure cases. Yes i did. > > The original class was defined just as you propose. We moved to > the current expected form to be able to write > > auto e =3D expected::make(1) // result is > expected > > > What is the use-case for the above that can not be rewritten using the=20 > implicit construction or make_expected (unfortunately, pdf doesn't=20 > contain much details for make_expected), and that would significantly=20 > benefit from not writing expected(1)? > > What about make_expected(T value) -> expected which would=20 > implicitly convert to expected? I don't see the necessity=20 > of make_expected to always use exception_ptr. We have already un implicit conversion from T to expected. The=20 reason for make_expected is to be explicit enough to have a uniqye type=20 as result. > > Others have already do the same remark, and we would not have any > problem rolling back to the original design. We will need a > different type constructor expected_tc (a better name of course) > > > If it is necessary, +1. > > We have already renamed fmap to map and mbind to bind as requested > in C++Now 2014. > > Cool. :) > > I have no problem in separating it into two proposals, one that > address the minimal interface of expected and one another that > address the monadic functions. > > > I'd really advise that approach - it would be a shame if the=20 > expected<...> class would get rejected or its inclusion postponed=20 > because of the other parts of the proposal needed polishing. I would have no problem, however we are a little bit too late to change=20 it for Raspewill. > > The problem I have is that I don't know how to address the concept > of Monad with the current C++ language. Non-members functions seem > to don't address the problem correctly as commented by Sebastian > Redl in an other post. > > > There is a dead thread that Vicente Escriba started some time ago:=20 > https://groups.google.com/a/isocpp.org/d/msg/std-proposals/KCqwEq49GMA/a5= f117Z5yZkJ > Yes this Vicente is me. > And yes, making Monads will be painful. > > We could add the member functions map/bind/catch_error to > optional and future without too much difficulties. The same > could apply to any std container class, but we couldn't see T* or > T[N] as a Monad. > > > Maybe it could follow the same approach as member and non-member=20 > begin/end. Though, in all honesty, I don't really care about raw=20 > pointers and arrays. Maybe. - Would this mean that we have to add the map/bins/cacth_error/unit as=20 member functions and that the default forwards to members functions? - non-member functions don't chain as well as member functions. - we will need infix operators > > What do you find strange? Do you mean that it sounds strange in > English? > > Yes, the word is not recognized by Merriam-Webster nor Oxford=20 > dictionary. But this is more of a nit-pick than anything else. > Oh I understand why you find it estrange now :( Vicente --=20 ---=20 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 e= mail 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-proposa= ls/. --------------000306040301030003010009 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le 24/05/14 17:58, Ivan =C4=8Cuki=C4=87 = a =C3=A9crit=C2=A0:
I guess you have considered a lot of different options.

Is there a publicly accessible log of the discussions? Otherwise I have no choice but to bother you with more questions. :)
=C2=A0
in [1] ErrorT is a n error monad transformer that takes an error e and another monad m. expected doesn't takes an error type and a monad, but a type.

Yes, but I hope you got my point regarding the naming. I'd rather that the api caters to the "happy path" (to quote E. Meijer) than to the failure cases.
Yes i did.
=C2=A0
The original class was defined just as you propose. We moved to the current expected<E,T> form to be able to write

auto e=C2=A0 =3D expected<error_condition>::make(1) = // result is expected<error_condition, int>

What is the use-case for the above that can not be rewritten using the implicit construction or make_expected (unfortunately, pdf doesn't contain much details for make_expected), and that would significantly benefit from not writing expected<int, error_condition>(1)?

What about make_expected(T value) -> expected<T, void> which would implicitly convert to expected<T, AnyType>? I don't see the necessity of make_expected to always use exception_ptr.
We have already un implicit conversion from T to expected<E,T>. The reason for make_expected is to be explicit enough to have a uniqye type as result.
=C2=A0
Others have already do the same remark, and we would not have any problem rolling back to the original design. We will need a different type constructor expected_tc (a better name of course)

If it is necessary, +1.

We have already renamed fmap to map and mbind to bind as requested in C++Now 2014.
=C2=A0
Cool. :)=C2=A0

I have no problem in separating it into two proposals, one that address the minimal interface of expected and one another that address the monadic functions.

I'd really advise that approach - it would be a shame if the expected<...> class would get rejected or its inclusion postponed because of the other parts of the proposal needed polishing.
I would have no problem, however we are a little bit too late to change it for Raspewill.
=C2=A0
The problem I have is that I don't know how to address the concept of Monad with the current C++ language. Non-members functions seem to don't address the problem correctly as commented by Sebastian Redl in an other post.

There is a dead thread that Vicente Escriba started some time ago: https://groups.google.= com/a/isocpp.org/d/msg/std-proposals/KCqwEq49GMA/a5f117Z5yZkJ

Yes this Vicente is me.
And yes, making Monads will be painful.
=C2=A0
We could add the member functions map/bind/catch_error to optional<T> and future<T> without too much difficulties. The same could apply to any std container class, but we couldn't see T* or T[N] as a Monad.

Maybe it could follow the same approach as member and non-member begin/end. Though, in all honesty, I don't really care about raw pointers and arrays.
Maybe.
- Would this mean that we have to add the map/bins/cacth_error/unit as member functions and that the default forwards to members functions?
- non-member functions don't chain as well as member functions.
- we will need infix operators
=C2=A0
What do you find strange? Do you mean that it sounds strange in English?
=C2=A0
Yes, the word is not recognized by Merriam-Webster nor Oxford dictionary. But this is more of a nit-pick than anything else.

Oh I understand why you find it estrange now :(

Vicente

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--------------000306040301030003010009-- .