Proposal: Add bifunctor related classes to base

[Oliver Charles]

While I can't say I've ever reached for Bi* type classes, the argument to
move people away from Control.Arrow for what is generally Either-specific
functionality is a strong one. Furthermore, this stuff seems quite common
(I've seen bifunctors come up in a few papers now).

+1!

- ocharles


On Fri, Apr 25, 2014 at 5:02 PM, Dan Doel <dan.doel 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. So I've taken it upon
> myself to do so.
>
>
> The following proposal is to add some modules of the bifunctors [1]
> package to base, namely:
>
>     Data.Bifunctor
>     Data.Bifoldable
>     Data.Bitraversable
>
> These modules contain classes and functions for working with types similar
> to those identified by Functor, Foldable and Traversable, except that there
> are parameterized by two 'element types' so to speak.
>
>
> The advantages of this change are among the following:
>
> These are the right abstractions for many operations. For instance, Arrow
> is often recommended if someone wants to map over both sides (or the left
> side) of a pair. In fact, I'd wager that it is the single most common
> reason for recommending use of Arrow. But this is not really what Arrow was
> designed to accomplish. This is exactly what Bifunctor is for, though, and
> it abstracts over this kind of operation with pairs, Either, and in my
> experience many custom data types.
>
> Placement in base gives a better opportunity for people to find these
> right abstractions. 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. If Bifunctor were in base, the documentation for
> Either would note that it is one.
>
>
> Some things to consider:
>
> The API of the modules will shrink a bit due to Applicative becoming a
> superclass of Monad in 7.10. There is no reason for a separate bitraverse
> and bimapM and so on. Some things will likely be renamed, as well;
> bisequenceA => bisequence, for instance.
>
> The 'first' and 'second' functions in Data.Bifunctor overlap with Arrow.
> This actually means that they are a drop-in replacement for the commonly
> suggested misuse of Arrow.
>
> None of the dependencies of the bifunctors package are needed by the
> modules in question. They are used for other modules, or as part of an
> arbitrary decision of where to put an instance. For example, the tagged
> dependency is used to give instances for Tagged, but these could easily be
> moved into the tagged package if base were to adopt these classes.
>
>
> Discussion period: 2 weeks
>
> [1] http://hackage.haskell.org/package/bifunctors
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140425/7a8e9e3b/attachment.html>