> The previous discussion about methods on Either had some mention of adding bifunctors to base, but no one wrote up the details
I was implicitly leaving that to someone more qualified than me ;)
This proposal looks great to me, and I agree that it is the right abstraction for functions like mapLeft and such, instead of Arrows.
Still, some of the underlying assumptions made are not entirely clear to me:
> If someone goes into the documentation for Data.Either looking for a way
to map both parameters,
> they will not, of course, be directed to the
bifunctors package, even though it provides a good means of doing what
they want.
So, what you are proposing is that mapLeft and such are _not_ standalone functions in Data.Either, but instead we just add documentation refering them to bifunctors as the correct abstraction, a merge of my "Proposal 1" with "Proposal 8". Although I'm much more confortable with this than forwarding user to arrows, I still see a point in adding this basic functions in Data.Either.
It is my understanding that Data.List has a very complete API mainly for historical reasons, and that nowadays it is recomended to use Foldable and Traversable for many of those operations. The same applies to Data.Maybe. But a novice user will then look at Data.Either and Data.Tuple, and think: are these second class citizens?
I guess this is an entirely different discussion, that happend many times in the past with no relevant consensus...