Proposal: Add bifunctor related classes to base

[Edward Kmett]

On Mon, Apr 28, 2014 at 6:28 AM, João Cristóvão <jmacristovao at gmail.com>wrote:

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

I'm perfectly happy to say we should go through and put in documentation in
Data.Either and Data.Maybe talking about how they can be used with the
respective Data.Bifunctor and Control.Arrow combinators. That seems like
an obvious win with no downside.

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

I think it is worth voting on this independently of the Data.Either
additions, and would support adding the bifunctors machinery regardless of
what we do with 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...
>

The fact that "lists get their own special API" is really the exception not
the rule in base.

In fact, many types exported from Data.List will actually be generalizing
to avoid creating dozens of import conflicts with the Prelude as part of
the 7.10 transition. So pointing there to say here is an example of
something more monomorphic example than elsewhere is a bad idea.

I'm not in a hurry to see a huge proliferation of names for one-off
purposes.

That leaves me personally rather -1 on the majority of the Data.Either
proposal.

An additional question: would the arrow operators then be defined in terms
> of bifunctors?
>

The arrow combinators and the bifunctor combinators are not definable in
terms of one another except in special cases.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140428/114ddfc3/attachment.html>