Proposal: Add bifunctor related classes to base

[Edward Kmett]

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 <cam at uptoisomorphism.net> 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 <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
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries