Re: rfc: include bimap into Data.Either

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 fmap, I 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 < dominique.devriese@cs.kuleuven.be> 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 :

...

On 2014-04-20 at 17:29:39 +0200, Dominique Devriese wrote:

...

2014-04-20 14:29 GMT+02:00 Andreas Abel :

...

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 Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries