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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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.

yeah i checked there. unfortunately it's not as easy to improve hoogle... regards, tobias florek

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 :

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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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 Regards Dominique

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?

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 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 :

...

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?

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

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

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

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

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 mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

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