rfc: Additions to Data.Either (take 2)

[Eric Mertens]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140422/11ce4bae/attachment-0001.html>