rfc: include bimap into Data.Either

Carter Schonwald carter.schonwald at gmail.com
Sun Apr 20 21:37:05 UTC 2014


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 <andreas.abel at ifi.lmu.de>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 <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?
> >
>
>
> - --
> Andreas Abel  <><      Du bist der geliebte Mensch.
>
> Department of Computer Science and Engineering
> Chalmers and Gothenburg University, Sweden
>
> andreas.abel at gu.se
> 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
> 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/20140420/cc487a04/attachment.html>


More information about the Libraries mailing list