220 10800 <5380804B.80607@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: Sat, 24 May 2014 13:19:39 +0200 Lines: 339 Approved: news@gmane.org Message-ID: <5380804B.80607@wanadoo.fr> References: <94ded66f-1c50-47b9-8a04-b83805443da9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090906000103080601000203" X-Trace: ger.gmane.org 1400930388 30913 80.91.229.3 (24 May 2014 11:19:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 May 2014 11:19:48 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBTEAQKOAKGQENEMUV3Q@isocpp.org Sat May 24 13:19:42 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f199.google.com ([209.85.212.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wo9zK-00049T-GF for gclcip-std-proposals@m.gmane.org; Sat, 24 May 2014 13:19:42 +0200 Original-Received: by mail-wi0-f199.google.com with SMTP id cc10sf1060041wib.2 for ; Sat, 24 May 2014 04:19:42 -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=RmFQNXub5DDaqFKfzdKsE74WeZcbjo8nbC5HfC2kbls=; b=kKf7FpE1Wogqmus8RZpRGj6O1DWV4yhKSV+w5q7X486M4pX8QZiS8TGLGDtjg0DL+A t3ImTE/8zm0xLKEXPxT7dWhXxPvYJObjI3St8uvBbnlw6Dk4LKhVwuvvHjeAfOTX09le FfcexVIg36fWlbCUkKdgkVbW55qIPhMECi5CYlCNKko+4mgizfZ1PPiavjZ/rswoCjh5 TNmmSjauv2RtIqU8AHNiSHr7eVIjye814IlX2kJTYTy8y86kHQxr/7G2WRK65902f4Sv VaiiCuU1f7zpsZ0H9PyxTHIQyxDvt6TqSIv3lp+yIr+g8pYkad8AVTsEMyPDQ+cdwfoK LKJQ== X-Gm-Message-State: ALoCoQkB92FOly68Q3ksENjWN6INobrXy5x/krbOH6G6VdtFnRb6+45g4fpw1V2dEPj/rKx4C8yI X-Received: by 10.112.34.70 with SMTP id x6mr804841lbi.13.1400930382026; Sat, 24 May 2014 04:19:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.74.100 with SMTP id s4ls214920wiv.18.canary; Sat, 24 May 2014 04:19:40 -0700 (PDT) X-Received: by 10.180.74.108 with SMTP id s12mr10159075wiv.61.1400930380422; Sat, 24 May 2014 04:19:40 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr. [80.12.242.129]) by mx.google.com with ESMTP id r4si5645589wiv.24.2014.05.24.04.19.40 for ; Sat, 24 May 2014 04:19:40 -0700 (PDT) Received-SPF: none (google.com: vicente.botet@wanadoo.fr does not designate permitted sender hosts) client-ip=80.12.242.129; Original-Received: from new-host.home ([86.214.76.71]) by mwinf5d13 with ME id 5nKf1o00D1YJ2li03nKfBK; Sat, 24 May 2014 13:19:40 +0200 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Sat, 24 May 2014 13:19:40 +0200 X-ME-IP: 86.214.76.71 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: <94ded66f-1c50-47b9-8a04-b83805443da9@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:10800 Archived-At: This is a multi-part message in MIME format. --------------090906000103080601000203 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 24/05/14 11:46, Ivan =C4=8Cuki=C4=87 a =C3=A9crit : > Hi, > > Love the general idea. Was planning to propose it myself. I didn't go=20 > into details, so just a few general comments for the proposal. > Hi, > 1. > The main issue I have with it is the order of . In the haskell's=20 > error monad [1] the name implies that it is about errors, and the=20 > first argument is the error type. > in [1] ErrorT is a n error monad transformer that takes an error e and=20 another monad m. expected doesn't takes an error type and a monad, but a=20 type. expected could be equivalent as ErrorT, T> for=20 some expected_tc type constructor (see below). > This is the other side of the same coin, for 'expected' I'd expect the=20 > first argument to be the expected type. > > Exchanging the types would also allow to specify the default value of=20 > E to be std::exception_ptr. > > | > template > classexpected {...}; > | > > Otherwise, people will rather opt in to use std::optional because=20 > it is easier to write, and does not pollute the code. > The original class was defined just as you propose. We moved to the=20 current expected form to be able to write auto e =3D expected::make(1) // result is=20 expected Others have already do the same remark, and we would not have any=20 problem rolling back to the original design. We will need a different=20 type constructor expected_tc (a better name of course) auto e =3D expected_tc::make(1) // result is=20 expected > 2. > As for fmap, this will start the non-generic way of naming. futures=20 > have .then, this will have .fmap (and .then?), who knows how the next=20 > monad will name its bind operator. (IMO, this should be a part of=20 > another proposal, along with the all the stuff that require new=20 > core-language things like <-, and catch_exception {}) We have already renamed fmap to map and mbind to bind as requested in=20 C++Now 2014. I have no problem in separating it into two proposals, one that address=20 the minimal interface of expected and one another that address the=20 monadic functions. The problem I have is that I don't know how to=20 address the concept of Monad with the current C++ language. Non-members=20 functions seem to don't address the problem correctly as commented by=20 Sebastian Redl in an other post. Defining the functions as members has its own limitations, but at least=20 it allows to build on top of all the classes classes defining a similar=20 interface. We could add the member functions map/bind/catch_error to optional=20 and future without too much difficulties. The same could apply to any=20 std container class, but we couldn't see T* or T[N] as a Monad. > > 3. > Unexpect sounds strange :) > What do you find strange? Do you mean that it sounds strange in English? Pierre has suggested that we could replace unexpect expected e =3D {unexpect, a1, an}; by expected e =3D unexpeted_type{in_place, a1, an}; This would mean a in place constructor of the unexpected value and a=20 move to the expected storage. Vicente P.S. Note that the proposal use unexpeted_type as unexpected is already=20 used in the standard. > > [1] https://hackage.haskell.org/package/mtl-1.1.0.2/docs/Control-Monad-Er= ror.html > --=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/. --------------090906000103080601000203 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le 24/05/14 11:46, Ivan =C4=8Cuki=C4=87 = a =C3=A9crit=C2=A0:
Hi,

Love the general idea. Was planning to propose it myself. I didn't go into details, so just a few general comments for the proposal.

Hi,
1.
The main issue I have with it is the order of <E, T>. In the haskell's error monad [1] the name implies that it is about errors, and the first argument is the error type.

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.

expected<E,T> could be equivalent as ErrorT<E, expected_tc<E>, T> for some expected_tc type constructor (see below).
=C2=A0
This is the other side of the same coin, for 'expected' I'd expect the first argument to be the expected type.

Exchanging the types would also allow to specify the default value of E to be std::exception_ptr.

template <<= /span>typen= ame T, typen= ame E =3D std<= /span>::excep= tion_ptr><= /span>
class expected { ... };

Otherwise, people will rather opt in to use std::optional<T> because it is easier to write, and does not pollute the code.

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>

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)

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

2.
As for fmap, this will start the non-generic way of naming. futures have .then, this will have .fmap (and .then?), who knows how the next monad will name its bind operator. (IMO, this should be a part of another proposal, along with the all the stuff that require new core-language things like <-, and catch_exception {})

We have already renamed fmap to map and mbind to bind as requested in C++Now 2014.

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. 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.

Defining the functions as members has its own limitations, but at least it allows to build on top of all the classes classes defining a similar interface.

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.

3.
Unexpect sounds strange :)

What do you find strange? Do you mean that it sounds strange in English?

Pierre has suggested that we could replace unexpect

expected<E,T> e =3D {unexpect, a1, an};

by

expected<E,T> e =3D unexpeted_type{in_place, a1, an};

This would mean a in place constructor of the unexpected value and a move to the expected storage.


Vicente

P.S. Note that the proposal use unexpeted_type as unexpected is already used in the standard.


--

---
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>.
--------------090906000103080601000203-- .