rfc: include bimap into Data.Either

[Dominique Devriese]

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 <hvr at gnu.org>:
> On 2014-04-20 at 17:29:39 +0200, Dominique Devriese wrote:
>> 2014-04-20 14:29 GMT+02:00 Andreas Abel <andreas.abel at ifi.lmu.de>:
>>> 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?