Re: Proposal: Add bifunctor related classes to base

Biapplicative is left out because unlike the other two, it is underdetermined. There are at least two forms of biapplicative point. There are however, no such headaches with Bifunctor/Bifoldable/Bitraversable, which get nailed down hard by the laws. A very enthusiastic +1 on the proposal from me. -Edward

On Apr 25, 2014, at 12:28 PM, Casey McCann wrote:

Was Biapplicative left out of the proposal because of dependencies? It seems at least as useful as the others.

- C.

...

On Fri, Apr 25, 2014 at 12:02 PM, Dan Doel 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries