rfc: include bimap into Data.Either

[Edward Kmett]

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 at 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 <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?
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140421/33a5e70d/attachment.html>