rfc: include bimap into Data.Either

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

rfc: include bimap into Data.Either

Tobias Florek
hi,

i propose to include the following functions into Data.Either.

     mapLeft :: (a->b) -> Either a c -> Either b c
     mapLeft f = bimap f id

     bimap :: (a -> b) -> (c -> d) -> Either a c -> Either b d
     bimap f g = either (Left . f) (Right . g)

bimap and mapLeft already exists in edward kmett's either library (and
in categories-extras and in gabriel gonzales' errors), but imo they are
very useful by itself to warrant an inclusion in base. given bimap,
mapLeft might not cross the fairbairn threshold though.

note: i don't propose exporting them from Prelude.

discussion period: 2 weeks

cheers,
  tobias florek
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

Dan Doel
bimap is not a good name for this. There are too many things that can be bimapped, and they are abstracted over using the Bifunctor class in bifunctors, which has a method named bimap.

I also think people should just use Bifunctor, instead of one-off functions being added into several modules. But I could live with bimapEither existing, I suppose.

-- Dan


On Fri, Apr 18, 2014 at 4:54 PM, Tobias Florek <[hidden email]> wrote:
hi,

i propose to include the following functions into Data.Either.

    mapLeft :: (a->b) -> Either a c -> Either b c
    mapLeft f = bimap f id

    bimap :: (a -> b) -> (c -> d) -> Either a c -> Either b d
    bimap f g = either (Left . f) (Right . g)

bimap and mapLeft already exists in edward kmett's either library (and in categories-extras and in gabriel gonzales' errors), but imo they are very useful by itself to warrant an inclusion in base. given bimap, mapLeft might not cross the fairbairn threshold though.

note: i don't propose exporting them from Prelude.

discussion period: 2 weeks

cheers,
 tobias florek
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

Johan Tibell-2

How about 'mapBoth', since we're not mapping either of the options, but both of them. :)

On Apr 18, 2014 11:10 PM, "Dan Doel" <[hidden email]> wrote:
bimap is not a good name for this. There are too many things that can be bimapped, and they are abstracted over using the Bifunctor class in bifunctors, which has a method named bimap.

I also think people should just use Bifunctor, instead of one-off functions being added into several modules. But I could live with bimapEither existing, I suppose.

-- Dan


On Fri, Apr 18, 2014 at 4:54 PM, Tobias Florek <[hidden email]> wrote:
hi,

i propose to include the following functions into Data.Either.

    mapLeft :: (a->b) -> Either a c -> Either b c
    mapLeft f = bimap f id

    bimap :: (a -> b) -> (c -> d) -> Either a c -> Either b d
    bimap f g = either (Left . f) (Right . g)

bimap and mapLeft already exists in edward kmett's either library (and in categories-extras and in gabriel gonzales' errors), but imo they are very useful by itself to warrant an inclusion in base. given bimap, mapLeft might not cross the fairbairn threshold though.

note: i don't propose exporting them from Prelude.

discussion period: 2 weeks

cheers,
 tobias florek
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

Herbert Valerio Riedel
In reply to this post by Tobias Florek
On 2014-04-18 at 22:54:18 +0200, Tobias Florek wrote:
> i propose to include the following functions into Data.Either.
>
>     mapLeft :: (a->b) -> Either a c -> Either b c
>     mapLeft f = bimap f id
>
>     bimap :: (a -> b) -> (c -> d) -> Either a c -> Either b d
>     bimap f g = either (Left . f) (Right . g)

as these are just specialized versions of existing functions, i.e.

  mapLeft = Control.Arrow.left

  bimap = Control.Arrow.(+++)

I'm not convinced we should add these
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

Tobias Florek
>    mapLeft = Control.Arrow.left
>
>    bimap = Control.Arrow.(+++)

given arrowchoice, i withdraw my proposal. thank you for pointing me there.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

Henning Thielemann-4
Am 19.04.2014 12:28, schrieb Tobias Florek:
>>    mapLeft = Control.Arrow.left
>>
>>    bimap = Control.Arrow.(+++)
>
> given arrowchoice, i withdraw my proposal. thank you for pointing me there.

You may turn it into a proposal for Hoogle. :-) For the type of mapLeft
Hoogle lists only irrelevant results on the first page and for the type
of bimap it does not list a result, at all.

http://www.haskell.org/hoogle/?hoogle=%28a-%3Eb%29+-%3E+Either+a+c+-%3E+Either+b+c
http://www.haskell.org/hoogle/?hoogle=%28a+-%3E+b%29+-%3E+%28c+-%3E+d%29+-%3E+Either+a+c+-%3E+Either+b+d

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

Tobias Florek
> You may turn it into a proposal for Hoogle. :-) For the type of mapLeft
> Hoogle lists only irrelevant results on the first page and for the type
> of bimap it does not list a result, at all.

yeah i checked there. unfortunately it's not as easy to improve hoogle...

regards,
  tobias florek
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

Edward Kmett-2
-1 from me for the reason Herbert already stated: They are generalized by existing combinators already in base.

It may be worth adding documentation to Arrow about what they mean, but that of course doesn't help users trying to find them via hoogle.

-Edward


On Sat, Apr 19, 2014 at 7:06 AM, Tobias Florek <[hidden email]> wrote:
You may turn it into a proposal for Hoogle. :-) For the type of mapLeft
Hoogle lists only irrelevant results on the first page and for the type
of bimap it does not list a result, at all.

yeah i checked there. unfortunately it's not as easy to improve hoogle...

regards,
 tobias florek

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

João Cristóvão
> given arrowchoice, i withdraw my proposal. thank you for pointing me there.

Please don't.

While I agree that duplication is undesirable, I urge you all to consider the begginers and even intermediate haskeller point of view.

A search on hoogle will reveal nothing. A search on hayoo will reveal Data.Either.Combinators, but most users are not even aware of hoogle.

They will probably just google either and end up in Data.Either.

In Data.Either there is _absolutely_ no way to reach the Arrow combinators.
And even if the user somewhat finds Arrows, in an unrelated search, he will also not see the Either use case.

I would even argue that the Arrow abstraction is something that is in a totally different level than such a simple type as Either, and most haskellers will only use (arrows) much further ahead, but I agree this is highly arguable.

So:
> It may be worth adding documentation to Arrow about what they mean

Not only to arrows, please: this documentation is needed _on Data.Either_, which is where most users, I believe, would search for such a funcion.

Thanks
João


2014-04-19 15:50 GMT+01:00 Edward Kmett <[hidden email]>:
-1 from me for the reason Herbert already stated: They are generalized by existing combinators already in base.

It may be worth adding documentation to Arrow about what they mean, but that of course doesn't help users trying to find them via hoogle.

-Edward


On Sat, Apr 19, 2014 at 7:06 AM, Tobias Florek <[hidden email]> wrote:
You may turn it into a proposal for Hoogle. :-) For the type of mapLeft
Hoogle lists only irrelevant results on the first page and for the type
of bimap it does not list a result, at all.

yeah i checked there. unfortunately it's not as easy to improve hoogle...

regards,
 tobias florek

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

Andreas Abel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20.04.2014 07:16, João Cristóvão wrote:
>> given arrowchoice, i withdraw my proposal. thank you for pointing
>> me
> there.
>
> Please don't.

+1

Stuff like this belongs in Data.Either, not in Control.Arrow.  We had
the same issue for Data.Tuple vs. Control.Arrow a while ago.

> While I agree that duplication is undesirable, I urge you all to
> consider the begginers and even intermediate haskeller point of
> view.
>
> A search on hoogle will reveal nothing. A search on hayoo will
> reveal Data.Either.Combinators, but most users are not even aware
> of hoogle.
>
> They will probably just google either and end up in Data.Either.
>
> In Data.Either there is _absolutely_ no way to reach the Arrow
> combinators. And even if the user somewhat finds Arrows, in an
> unrelated search, he will also not see the Either use case.
>
> I would even argue that the Arrow abstraction is something that is
> in a totally different level than such a simple type as Either, and
> most haskellers will only use (arrows) much further ahead, but I
> agree this is highly arguable.
>
> So:
>> It may be worth adding documentation to Arrow about what they
>> mean
>
> Not only to arrows, please: this documentation is needed _on
> Data.Either_, which is where most users, I believe, would search
> for such a funcion.
>
> Thanks João
>
>
> 2014-04-19 15:50 GMT+01:00 Edward Kmett <[hidden email]
> <mailto:[hidden email]>>:
>
> -1 from me for the reason Herbert already stated: They are
> generalized by existing combinators already in base.
>
> It may be worth adding documentation to Arrow about what they
> mean, but that of course doesn't help users trying to find them via
> hoogle.
>
> -Edward
>
>
> On Sat, Apr 19, 2014 at 7:06 AM, Tobias Florek <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> You may turn it into a proposal for Hoogle. :-) For the type of
> mapLeft Hoogle lists only irrelevant results on the first page and
> for the type of bimap it does not list a result, at all.
>
>
> yeah i checked there. unfortunately it's not as easy to improve
> hoogle...
>
> regards, tobias florek
>
> _________________________________________________ Libraries mailing
> list [hidden email] <mailto:[hidden email]>
> http://www.haskell.org/__mailman/listinfo/libraries 
> <http://www.haskell.org/mailman/listinfo/libraries>
>
>
>
> _______________________________________________ Libraries mailing
> list [hidden email] <mailto:[hidden email]>
> http://www.haskell.org/mailman/listinfo/libraries
>
>
>
>
> _______________________________________________ Libraries mailing
> list [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>


- --
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNTvY4ACgkQPMHaDxpUpLMvMQCcCUYG6+Q/S5+Pn1hB48D8Znhe
5X8AnRLH3IIi2h+qVzoPAAb944w7tRQ1
=oGkn
-----END PGP SIGNATURE-----
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

Dominique Devriese-2
2014-04-20 14:29 GMT+02:00 Andreas Abel <[hidden email]>:

> On 20.04.2014 07:16, João Cristóvão wrote:
>>> given arrowchoice, i withdraw my proposal. thank you for pointing
>>> me
>> there.
>>
>> Please don't.
>
> +1
>
> Stuff like this belongs in Data.Either, not in Control.Arrow.  We had
> the same issue for Data.Tuple vs. Control.Arrow a while ago.

+1

Regards
Dominique
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

Tobias Florek
In reply to this post by João Cristóvão
hi,

what do you think about exporting the ArrowChoice function `left` from
Data.Either? both modules live in base, so i think the usual arguments
against reexporting don't apply (as much).

it might be needed to split the core of Data.Either into
Data.Either.Internal to let Control.Arrow break the dependency cycle though.

that will --of course-- not solve problem, that people might not
recognize that that's the function they need. but when exploring a
library interactively (ghci) a reexport might have give people a clue
that left _is_ what they want. and that other related functions might be
in Control.Arrow. i'm sure it would have for my part.


regarding the documentation enhancement: would the spelled-out instance
for (->) in Control.Arrow help? i mean: when a user knows to look into
Control.Arrow, it's not that hard to see, that left is the thing they
are looking for.


cheers,
  tobias florek
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

Herbert Valerio Riedel
In reply to this post by Dominique Devriese-2
On 2014-04-20 at 17:29:39 +0200, Dominique Devriese wrote:

> 2014-04-20 14:29 GMT+02:00 Andreas Abel <[hidden email]>:
>> On 20.04.2014 07:16, João Cristóvão wrote:
>>>> given arrowchoice, i withdraw my proposal. thank you for pointing
>>>> me
>>> there.
>>>
>>> Please don't.
>>
>> +1
>>
>> Stuff like this belongs in Data.Either, not in Control.Arrow.  We had
>> the same issue for Data.Tuple vs. Control.Arrow a while ago.
>
> +1

I'm slightly confused, what are you exactly voting for? For augmenting
the documentation in Data.Either to mentioning e.g. Control.Arrows (or
even Bifunctor), or rather for adding new functions to Data.Either?
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

Dominique Devriese-2
First, here is a link to a post by Andreas in a previous discussion on
this list about the same topic
 http://www.haskell.org/pipermail/libraries/2013-August/020549.html

Speaking only for myself, I would happily support a generalisation
like "mapEither is just a special case of Bifunctor.fmapBoth".
However, I'm unsatisfied with "mapEither is just a special case of
Control.Arrow.(+++)". The reason is that when I need, e.g., the
mapEither function, I'm looking for a function of type "(a -> b) -> (c
-> d) -> Either a c -> Either b d".  To find such a function, I focus
on the Eithers in this signature and start looking for a function
related to the Either data type, or some generalisation of it.  I
would naturally expect to find such a function in Data.Either or
Data.Bifunctor or similar places. However, in order to find
Control.Arrow.(+++), I would instead have to focus on the (->)s in the
signature and look for a function that works on a generalisation of
the (->)s, i.e. Arrow.  For me, and I expect also for beginners and
people unacquainted with arrows, I think this is *not* an obvious
generalisation.

As for a concrete counter-proposal, I would propose to amend Tobias'
original proposal with three bikeshedding modifications (partially
overlapping with other people's suggestion in this thread and the one
from 2013):
* rename bimap to mapEither (or perhaps mapBoth)
* implement the functions as renames when possible: "mapEither =
Control.Arrow.(+++)" and similarly.
* also add "mapRight :: (a -> b) -> Either c a -> Either c b"

Regards,
Dominique

2014-04-20 17:52 GMT+02:00 Herbert Valerio Riedel <[hidden email]>:

> On 2014-04-20 at 17:29:39 +0200, Dominique Devriese wrote:
>> 2014-04-20 14:29 GMT+02:00 Andreas Abel <[hidden email]>:
>>> On 20.04.2014 07:16, João Cristóvão wrote:
>>>>> given arrowchoice, i withdraw my proposal. thank you for pointing
>>>>> me
>>>> there.
>>>>
>>>> Please don't.
>>>
>>> +1
>>>
>>> Stuff like this belongs in Data.Either, not in Control.Arrow.  We had
>>> the same issue for Data.Tuple vs. Control.Arrow a while ago.
>>
>> +1
>
> I'm slightly confused, what are you exactly voting for? For augmenting
> the documentation in Data.Either to mentioning e.g. Control.Arrows (or
> even Bifunctor), or rather for adding new functions to Data.Either?
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

Andreas Abel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

+1 to all three amendments.

On 20.04.2014 19:20, Dominique Devriese wrote:

> First, here is a link to a post by Andreas in a previous discussion
> on this list about the same topic
> http://www.haskell.org/pipermail/libraries/2013-August/020549.html
>
> Speaking only for myself, I would happily support a generalisation
> like "mapEither is just a special case of Bifunctor.fmapBoth".
> However, I'm unsatisfied with "mapEither is just a special case of
> Control.Arrow.(+++)". The reason is that when I need, e.g., the
> mapEither function, I'm looking for a function of type "(a -> b) ->
> (c -> d) -> Either a c -> Either b d".  To find such a function, I
> focus on the Eithers in this signature and start looking for a
> function related to the Either data type, or some generalisation of
> it.  I would naturally expect to find such a function in
> Data.Either or Data.Bifunctor or similar places. However, in order
> to find Control.Arrow.(+++), I would instead have to focus on the
> (->)s in the signature and look for a function that works on a
> generalisation of the (->)s, i.e. Arrow.  For me, and I expect also
> for beginners and people unacquainted with arrows, I think this is
> *not* an obvious generalisation.
>
> As for a concrete counter-proposal, I would propose to amend
> Tobias' original proposal with three bikeshedding modifications
> (partially overlapping with other people's suggestion in this
> thread and the one from 2013): * rename bimap to mapEither (or
> perhaps mapBoth) * implement the functions as renames when
> possible: "mapEither = Control.Arrow.(+++)" and similarly. * also
> add "mapRight :: (a -> b) -> Either c a -> Either c b"
>
> Regards, Dominique
>
> 2014-04-20 17:52 GMT+02:00 Herbert Valerio Riedel <[hidden email]>:
>> On 2014-04-20 at 17:29:39 +0200, Dominique Devriese wrote:
>>> 2014-04-20 14:29 GMT+02:00 Andreas Abel
>>> <[hidden email]>:
>>>> On 20.04.2014 07:16, João Cristóvão wrote:
>>>>>> given arrowchoice, i withdraw my proposal. thank you for
>>>>>> pointing me
>>>>> there.
>>>>>
>>>>> Please don't.
>>>>
>>>> +1
>>>>
>>>> Stuff like this belongs in Data.Either, not in Control.Arrow.
>>>> We had the same issue for Data.Tuple vs. Control.Arrow a
>>>> while ago.
>>>
>>> +1
>>
>> I'm slightly confused, what are you exactly voting for? For
>> augmenting the documentation in Data.Either to mentioning e.g.
>> Control.Arrows (or even Bifunctor), or rather for adding new
>> functions to Data.Either?
>


- --
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNUIx4ACgkQPMHaDxpUpLN8UgCg4Jiu1+QtQE5BxlBW6Uzo1XoX
ucUAnjDHfOT6TmgAzT1Jt/Qv3spkhrA5
=Dw+D
-----END PGP SIGNATURE-----
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

Carter Schonwald
can the people with new proposals do new threads, adding ammendments inline to a preexisting thread makes it really hard 

a) to know who supports what
b) make it visible to folks who've started ignoring the thread they've already voted on 


On Sun, Apr 20, 2014 at 3:42 PM, Andreas Abel <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

+1 to all three amendments.

On 20.04.2014 19:20, Dominique Devriese wrote:
> First, here is a link to a post by Andreas in a previous discussion
> on this list about the same topic
> http://www.haskell.org/pipermail/libraries/2013-August/020549.html
>
> Speaking only for myself, I would happily support a generalisation
> like "mapEither is just a special case of Bifunctor.fmapBoth".
> However, I'm unsatisfied with "mapEither is just a special case of
> Control.Arrow.(+++)". The reason is that when I need, e.g., the
> mapEither function, I'm looking for a function of type "(a -> b) ->
> (c -> d) -> Either a c -> Either b d".  To find such a function, I
> focus on the Eithers in this signature and start looking for a
> function related to the Either data type, or some generalisation of
> it.  I would naturally expect to find such a function in
> Data.Either or Data.Bifunctor or similar places. However, in order
> to find Control.Arrow.(+++), I would instead have to focus on the
> (->)s in the signature and look for a function that works on a
> generalisation of the (->)s, i.e. Arrow.  For me, and I expect also
> for beginners and people unacquainted with arrows, I think this is
> *not* an obvious generalisation.
>
> As for a concrete counter-proposal, I would propose to amend
> Tobias' original proposal with three bikeshedding modifications
> (partially overlapping with other people's suggestion in this
> thread and the one from 2013): * rename bimap to mapEither (or
> perhaps mapBoth) * implement the functions as renames when
> possible: "mapEither = Control.Arrow.(+++)" and similarly. * also
> add "mapRight :: (a -> b) -> Either c a -> Either c b"
>
> Regards, Dominique
>
> 2014-04-20 17:52 GMT+02:00 Herbert Valerio Riedel <[hidden email]>:
>> On 2014-04-20 at 17:29:39 +0200, Dominique Devriese wrote:
>>> 2014-04-20 14:29 GMT+02:00 Andreas Abel
>>> <[hidden email]>:
>>>> On 20.04.2014 07:16, João Cristóvão wrote:
>>>>>> given arrowchoice, i withdraw my proposal. thank you for
>>>>>> pointing me
>>>>> there.
>>>>>
>>>>> Please don't.
>>>>
>>>> +1
>>>>
>>>> Stuff like this belongs in Data.Either, not in Control.Arrow.
>>>> We had the same issue for Data.Tuple vs. Control.Arrow a
>>>> while ago.
>>>
>>> +1
>>
>> I'm slightly confused, what are you exactly voting for? For
>> augmenting the documentation in Data.Either to mentioning e.g.
>> Control.Arrows (or even Bifunctor), or rather for adding new
>> functions to Data.Either?
>


- --
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNUIx4ACgkQPMHaDxpUpLN8UgCg4Jiu1+QtQE5BxlBW6Uzo1XoX
ucUAnjDHfOT6TmgAzT1Jt/Qv3spkhrA5
=Dw+D
-----END PGP SIGNATURE-----
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

Alexander Berntsen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 20/04/14 23:37, Carter Schonwald wrote:
> can the people with new proposals do new threads, adding ammendments
> inline to a preexisting thread makes it really hard
>
> a) to know who supports what
> b) make it visible to folks who've
> started ignoring the thread they've already voted on
+1 ;-)

- --
Alexander
[hidden email]
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlNVB0wACgkQRtClrXBQc7UeSwEAqDC7LhAmeG2mNmSDQ9D33ulE
+WIBcp4t66nD8H519XwA/jtSYbEZ+oq2DdtXIxAWDSeNDn53XyOiZdR4vpFCPzTm
=cFB+
-----END PGP SIGNATURE-----
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

Edward Kmett-2
In reply to this post by Dominique Devriese-2
If your objection is that you find the choice of Bifunctor a more natural axis upon which to generalize than Arrow, I happen to agree.

If the proposal was to bring in the core of bifunctors into base (e.g. Data.Bifunctor, Data.Bifoldable, Data.Bitraversable), I'd be an enthusiastic +1.

I am, however, strongly against adding a mapRight in a world with fmapI mean before you know it we'd be using a special map for lists! ;)

-Edward


On Sun, Apr 20, 2014 at 1:20 PM, Dominique Devriese <[hidden email]> wrote:
First, here is a link to a post by Andreas in a previous discussion on
this list about the same topic
 http://www.haskell.org/pipermail/libraries/2013-August/020549.html

Speaking only for myself, I would happily support a generalisation
like "mapEither is just a special case of Bifunctor.fmapBoth".
However, I'm unsatisfied with "mapEither is just a special case of
Control.Arrow.(+++)". The reason is that when I need, e.g., the
mapEither function, I'm looking for a function of type "(a -> b) -> (c
-> d) -> Either a c -> Either b d".  To find such a function, I focus
on the Eithers in this signature and start looking for a function
related to the Either data type, or some generalisation of it.  I
would naturally expect to find such a function in Data.Either or
Data.Bifunctor or similar places. However, in order to find
Control.Arrow.(+++), I would instead have to focus on the (->)s in the
signature and look for a function that works on a generalisation of
the (->)s, i.e. Arrow.  For me, and I expect also for beginners and
people unacquainted with arrows, I think this is *not* an obvious
generalisation.

As for a concrete counter-proposal, I would propose to amend Tobias'
original proposal with three bikeshedding modifications (partially
overlapping with other people's suggestion in this thread and the one
from 2013):
* rename bimap to mapEither (or perhaps mapBoth)
* implement the functions as renames when possible: "mapEither =
Control.Arrow.(+++)" and similarly.
* also add "mapRight :: (a -> b) -> Either c a -> Either c b"

Regards,
Dominique

2014-04-20 17:52 GMT+02:00 Herbert Valerio Riedel <[hidden email]>:
> On 2014-04-20 at 17:29:39 +0200, Dominique Devriese wrote:
>> 2014-04-20 14:29 GMT+02:00 Andreas Abel <[hidden email]>:
>>> On 20.04.2014 07:16, João Cristóvão wrote:
>>>>> given arrowchoice, i withdraw my proposal. thank you for pointing
>>>>> me
>>>> there.
>>>>
>>>> Please don't.
>>>
>>> +1
>>>
>>> Stuff like this belongs in Data.Either, not in Control.Arrow.  We had
>>> the same issue for Data.Tuple vs. Control.Arrow a while ago.
>>
>> +1
>
> I'm slightly confused, what are you exactly voting for? For augmenting
> the documentation in Data.Either to mentioning e.g. Control.Arrows (or
> even Bifunctor), or rather for adding new functions to Data.Either?
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

Joachim Breitner-2
In reply to this post by Dominique Devriese-2
Hi,

Am Sonntag, den 20.04.2014, 19:20 +0200 schrieb Dominique Devriese:
> * rename bimap to mapEither (or perhaps mapBoth)

+1

> * implement the functions as renames when possible: "mapEither =
> Control.Arrow.(+++)" and similarly.

*shrug* doesn’t really matter (unless this would hurt performance)

> * also add "mapRight :: (a -> b) -> Either c a -> Either c b"

+1


Thinking in expertise levels, using Either comes much earlier than using
ArrowChoice, and we should also suit the users that are on that level. A
reference to the more advanced functions should be added to the haddock.

Greetings,
Joachim

--
Joachim “nomeata” Breitner
  [hidden email]http://www.joachim-breitner.de/
  Jabber: [hidden email]  • GPG-Key: 0xF0FBF51F
  Debian Developer: [hidden email]


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: include bimap into Data.Either

Iavor Diatchki
In reply to this post by Dominique Devriese-2
Hello,


On Sun, Apr 20, 2014 at 10:20 AM, Dominique Devriese <[hidden email]> wrote:
First, here is a link to a post by Andreas in a previous discussion on
this list about the same topic
 http://www.haskell.org/pipermail/libraries/2013-August/020549.html


I think this makes a very good point.
 
* rename bimap to mapEither (or perhaps mapBoth)
(+1)
 
* implement the functions as renames when possible: "mapEither =
Control.Arrow.(+++)" and similarly.

(+0) {- To me it seems more natural to have the overloaded versions be in terms of the concrete ones,
rather then the other way around (i.e., the arrow instance should use `mapEither`). -}
 
* also add "mapRight :: (a -> b) -> Either c a -> Either c b"

(+1)
 
-Iavor



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
12