220 10804 <0e4dbb0e-0a7e-4164-be4e-60e114b18548@isocpp.org> article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Ivan_=C4=8Cuki=C4=87?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: N4015: A proposal to add a utility class to represent expected monad Date: Sat, 24 May 2014 08:58:19 -0700 (PDT) Lines: 200 Approved: news@gmane.org Message-ID: <0e4dbb0e-0a7e-4164-be4e-60e114b18548@isocpp.org> References: <94ded66f-1c50-47b9-8a04-b83805443da9@isocpp.org> <5380804B.80607@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_132_10615477.1400947099873" X-Trace: ger.gmane.org 1400947116 5773 80.91.229.3 (24 May 2014 15:58:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 May 2014 15:58:36 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD6M5NX6WAFRBHEDQOOAKGQEQA5XKQY@isocpp.org Sat May 24 17:58:25 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f199.google.com ([209.85.216.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WoEL0-0003EC-B6 for gclcip-std-proposals@m.gmane.org; Sat, 24 May 2014 17:58:22 +0200 Original-Received: by mail-qc0-f199.google.com with SMTP id i17sf20912798qcy.6 for ; Sat, 24 May 2014 08:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=hk8lLQuA+4V5KqmDw5MX3Js54QDAvQHjRiRDV7/At34=; b=twN+ofq85r6M/wClK6Mnbn4elwN6ViD/wQvAwCmEE/ByLFgaTpQbgPk6f+7dBSWyyR Fxl5NmgfVge4ok2mYggmlXx7pJHmMsAhjmBQuIqFDvZYgMS5d9ewzJBTlwkrSXv6k2fp aTR1BMwQ4DsIojvXlg9esVcDO3L+xjkkargyILDC6aR6ZlWmC9PoK/ECNewkMBt9C/6x S1qX3tzdyv7O5Mp/ET91XS+Z5AyDq8QEMYzqea6NsMup9DHtiSP9YLPjldGbE6bzVyK+ 2+IOBa1ei2f3N08PmZ3ZouuyJ2MHloTtDMexub24FnvjMLNs56faY4XvK4vghRT/BwI5 /a2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=hk8lLQuA+4V5KqmDw5MX3Js54QDAvQHjRiRDV7/At34=; b=AiHMwLqopjr2ANzNr0sLekEjs+EhEPJVXDmiTFFICMvvldmcRag1rurmK5IuOWyG1d JX6iS5blfJyw1QXC6tlOEjX/hO6Z9m6bRrw1E5Wce+QTZLLdtHnG+3ePcob2uuigxIra QVRRr37bVvqV54KKQzeBAkDCfeiEbv8+eNJw9jwBSPf3lqgkZQea9Xba8DAADauBsUru wcclaEdXent/uhd31BN1xwoVArLDpWrz+/pXt1bR3h0rvZJ04fOVnwnmBaC1TdlNUN0a mjX6cRPn+Gk/cAGioOsPFI+ptYCQbzI+mauGxKUVAGaK1+pgKVUvSIHCjTDAg1Omghli a7ZA== X-Gm-Message-State: ALoCoQlUHeysozNjJB6wXMcPQulSrSh+xxhc2ThgcN+lPh3BibQdZtpxIM3yF1gz30k0WqRuQSfm X-Received: by 10.236.141.11 with SMTP id f11mr5088214yhj.54.1400947101369; Sat, 24 May 2014 08:58:21 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.100.179 with SMTP id s48ls2062155qge.17.gmail; Sat, 24 May 2014 08:58:20 -0700 (PDT) X-Received: by 10.140.38.199 with SMTP id t65mr625qgt.17.1400947100727; Sat, 24 May 2014 08:58:20 -0700 (PDT) In-Reply-To: <5380804B.80607@wanadoo.fr> X-Original-Sender: ivan.cukic@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:10804 Archived-At: ------=_Part_132_10615477.1400947099873 Content-Type: text/plain; charset=UTF-8 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. :) > 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. > The original class was defined just as you propose. We moved to the > current expected form to be able to write > > auto e = expected::make(1) // result is > expected > 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(1)? What about make_expected(T value) -> expected which would implicitly convert to expected? I don't see the necessity of make_expected to always use exception_ptr. > 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 expected<...> class would get rejected or its inclusion postponed because of the other parts of the proposal needed polishing. > 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 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 begin/end. Though, in all honesty, I don't really care about raw pointers and arrays. > 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 dictionary. But this is more of a nit-pick than anything else. Cheerio, and thanks for the quick response! Ivan -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_132_10615477.1400947099873 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I guess you have considered a lot of different option= s.

Is there a publicly accessible log of the discu= ssions? Otherwise I have no choice but to bother you with more questions. := )
 
in [1] ErrorT is a n error monad transf= ormer 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 cater= s to the "happy path" (to quote E. Meijer) than to the failure cases.
=
 
The original class was defined just as you pr= opose. We moved to the current expected<E,T> form to be able to write

auto e  =3D expected<error_condition>::make(1) // resul= t 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 cont= ain much details for make_expected), and that would significantly benefit f= rom 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_e= xpected to always use exception_ptr.
 
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.

<= /div>
We have already renamed fmap to map and mbind to bind as r= equested in C++Now 2014.
 
Cool. :)&nb= sp;

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<...&= gt; class would get rejected or its inclusion postponed because of the othe= r parts of the proposal needed polishing.
 
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/KCqwE= q49GMA/a5f117Z5yZkJ

And yes, making Monads will be painfu= l.
 
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. Thoug= h, in all honesty, I don't really care about raw pointers and arrays.
=
 
What do you find strange? Do you mean that it so= unds strange in English?
 
Yes, the word is n= ot recognized by Merriam-Webster nor Oxford dictionary. But this is more of= a nit-pick than anything else.


Cheer= io, and thanks for the quick response!
Ivan

--

---
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>.
------=_Part_132_10615477.1400947099873-- .