And my own votes: 0) (-1) 1) (-1) 2) (+1) 3.a) (+1) 3.b) (0) 3.c) (+1) 4.a) (+1) 4.b) (0) 4.c) (+1) 5) (0) 6a) (-1) 6b) (-1) 7) (+1) 8) (+1) 2014-04-21 21:01 GMT+01:00 João Cristóvão :

Hello,

So following Carter Schonwald suggestion of creating a new thread, but not literally, since the amount of combinations would be huge, here is my own humble attempt to gather all hypothesis discussed into separate proposals, for your voting pleasure. (Some are mutually exclusive, some are not)

Proposal 0: ----------------

Do nothing

Proposal 1: ---------------- Add no new code, but document Data.Either to mention how to use `left` and (+++) from Control.Arrow

Proposal 2: ---------------- Document Control.Arrow to exemplify the (->) instance usage.

Proposal 3: ----------------

Implement mapLeft in Data.Either

3a) ... as (a -> b) -> Either a c -> Either b c (so that is easy to follow) 3b) ... as Control.Arrow.left 3c) ... and also redefine the -> instance of Control.Arrow.left as mapLeft

Proposal 4: ----------------

Implement mapBoth in Data.Either

4a) ... as (a -> b) -> (c -> d) -> Either a c -> Either b d (so that is easy to follow) 4b) ... as Control.Arrow.(+++) 4c) ... and also redefine the -> instance of Control.Arrow.(+++) as mapBoth

Proposal 5: ----------------

== Proposal 4, using the mapEither name instead.

Proposal 6: ----------------

Implement mapRight in Data.Either

6a) ... as (b -> c) -> Either a b -> Either a c 6b) ... as fmap

Proposal 7: ----------------

Don't implement mapRight, but include documentation in Data.Either stating that it is just fmap.

Proposal 8: ----------------

Bring bifunctors to base.

thanks joão for the write-up.

Proposal 1: Add no new code, but document Data.Either to mention how to use `left` and (+++) from Control.Arrow

(+1 for documentation, but that's not what that proposal is about)

Proposal 2: Document Control.Arrow to exemplify the (->) instance usage.

+1

Proposal 7: Don't implement mapRight, but include documentation in Data.Either stating that it is just fmap.

+1

Proposal 8: Bring bifunctors to base.

(my favorite by far) +1 all others i am ignorant about. cheers, tobias florek

On Mon, Apr 21, 2014 at 9:01 PM, João Cristóvão wrote:

Proposal 0: ----------------

Do nothing

Seeing as this has come up a bunch of times, -1 - as we clearly need to do *something*. Proposal 1:

---------------- Add no new code, but document Data.Either to mention how to use `left` and (+++) from Control.Arrow

+1

Proposal 2: ---------------- Document Control.Arrow to exemplify the (->) instance usage.

More examples is in general a good idea - I see no harm in this. +1

Proposal 3: ----------------

Proposal 4:

----------------

Proposal 5: ----------------

== Proposal 4, using the mapEither name instead.

Indifferent on these.

Proposal 6: ----------------

Implement mapRight in Data.Either

6a) ... as (b -> c) -> Either a b -> Either a c 6b) ... as fmap

-1 on this, as we don't have 'mapJust' and Functor is hardly an esoteric type class. Proposal 7:

----------------

Don't implement mapRight, but include documentation in Data.Either stating that it is just fmap.

Again, more documentation is almost always a good thing. +1 Proposal 8:

----------------

Bring bifunctors to base.

-1, and seems at ends with the split base proposals. I don't see much value in growing base a whole lot more. I'm probably opening a whole 'nother can of worms. Apologies ;)

- ocharles

On 2014-04-21 at 22:01:34 +0200, João Cristóvão wrote:

Proposal 1: ---------------- Add no new code, but document Data.Either to mention how to use `left` and (+++) from Control.Arrow

+1

Proposal 2: ---------------- Document Control.Arrow to exemplify the (->) instance usage.

+1

Proposal 3: ----------------

Implement mapLeft in Data.Either

3a) ... as (a -> b) -> Either a c -> Either b c (so that is easy to follow) 3b) ... as Control.Arrow.left 3c) ... and also redefine the -> instance of Control.Arrow.left as mapLeft

-1

Proposal 4: ----------------

Implement mapBoth in Data.Either

4a) ... as (a -> b) -> (c -> d) -> Either a c -> Either b d (so that is easy to follow) 4b) ... as Control.Arrow.(+++) 4c) ... and also redefine the -> instance of Control.Arrow.(+++) as mapBoth

-1

Proposal 5: ----------------

== Proposal 4, using the mapEither name instead.

-1

Proposal 6: ----------------

Implement mapRight in Data.Either

6a) ... as (b -> c) -> Either a b -> Either a c 6b) ... as fmap

-1

Proposal 7: ----------------

Don't implement mapRight, but include documentation in Data.Either stating that it is just fmap.

+1

Proposal 8: ----------------

Bring bifunctors to base.

+1 (btw, afaik the idea is to bring only the core parts of bifunctors into base)

Proposal 0: ----------------

Do nothing

(+1) I'd be OK with the outcome being nothing changing, but in the case that it doesn't I have the following take

Proposal 1: ---------------- Add no new code, but document Data.Either to mention how to use `left` and (+++) from Control.Arrow

(-1) I don't find Control.Arrow to be a compelling abstraction and I don't want to drive more people to it only to use it simply for its (->) instances. Additionally I don't want think that learning more operators is the solution to applying functions to Either values.

Proposal 2: ---------------- Document Control.Arrow to exemplify the (->) instance usage.

(0) I'm OK with any changes that happen inside the Control.Arrow module

Proposal 3: ----------------

Implement mapLeft in Data.Either

3a) ... as (a -> b) -> Either a c -> Either b c (so that is easy to follow) 3b) ... as Control.Arrow.left 3c) ... and also redefine the -> instance of Control.Arrow.left as mapLeft

(+1) for 3a. We don't need Arrow leaking out of its module. mapLeft is the actual operation in question. A user looking for operations on Either can switch to a more general operation later when it turns out he's writing a more general function.

Proposal 4: ----------------

Implement mapBoth in Data.Either

4a) ... as (a -> b) -> (c -> d) -> Either a c -> Either b d (so that is easy to follow) 4b) ... as Control.Arrow.(+++) 4c) ... and also redefine the -> instance of Control.Arrow.(+++) as mapBoth

(-1) the Both name invokes tuples for me

Proposal 5: ----------------

== Proposal 4, using the mapEither name instead.

(+1) same as 3a

Proposal 6: ----------------

Implement mapRight in Data.Either

6a) ... as (b -> c) -> Either a b -> Either a c 6b) ... as fmap

(+1) 6a. The code should be clear and gains nothing by exposing fmap's type or implementation and it should be an error for someone to use mapRight on a non-Either value

Proposal 7: ----------------

Don't implement mapRight, but include documentation in Data.Either stating that it is just fmap.

(-1) While it is true that fmap is mapRight for Either, that doesn't mean that the mapRight operation doesn't stand on its own.

Proposal 8: ----------------

Bring bifunctors to base.

(0) I'm fine with bifunctors moving into base, but I don't think it's relevant to this discussion. While it is the case that the Bifunctor abstraction also subsumes a map[Left,Right,Either], these operations continue to stand on there own. I'd advocate for using the general operations when the generality is called for and useful, not as a way to save on names. I similarly consider it inappropriate to remove (.) in favor of fmap