<div dir="ltr">+1</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 25, 2014 at 12:14 PM, Niklas Haas <span dir="ltr"><<a href="mailto:haskell@nand.wakku.to" target="_blank">haskell@nand.wakku.to</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, 25 Apr 2014 12:02:33 -0400, Dan Doel <<a href="mailto:dan.doel@gmail.com">dan.doel@gmail.com</a>> wrote:<br>


> The previous discussion about methods on Either had some mention of adding<br>
> bifunctors to base, but no one wrote up the details. So I've taken it upon<br>
> myself to do so.<br>
><br>
><br>
> The following proposal is to add some modules of the bifunctors [1] package<br>
> to base, namely:<br>
><br>
> Â  Â  Data.Bifunctor<br>
> Â  Â  Data.Bifoldable<br>
> Â  Â  Data.Bitraversable<br>
><br>
> These modules contain classes and functions for working with types similar<br>
> to those identified by Functor, Foldable and Traversable, except that there<br>
> are parameterized by two 'element types' so to speak.<br>
><br>
><br>
> The advantages of this change are among the following:<br>
><br>
> These are the right abstractions for many operations. For instance, Arrow<br>
> is often recommended if someone wants to map over both sides (or the left<br>
> side) of a pair. In fact, I'd wager that it is the single most common<br>
> reason for recommending use of Arrow. But this is not really what Arrow was<br>
> designed to accomplish. This is exactly what Bifunctor is for, though, and<br>
> it abstracts over this kind of operation with pairs, Either, and in my<br>
> experience many custom data types.<br>
><br>
> Placement in base gives a better opportunity for people to find these right<br>
> abstractions. If someone goes into the documentation for Data.Either<br>
> looking for a way to map both parameters, they will not, of course, be<br>
> directed to the bifunctors package, even though it provides a good means of<br>
> doing what they want. If Bifunctor were in base, the documentation for<br>
> Either would note that it is one.<br>
><br>
><br>
> Some things to consider:<br>
><br>
> The API of the modules will shrink a bit due to Applicative becoming a<br>
> superclass of Monad in 7.10. There is no reason for a separate bitraverse<br>
> and bimapM and so on. Some things will likely be renamed, as well;<br>
> bisequenceA => bisequence, for instance.<br>
><br>
> The 'first' and 'second' functions in Data.Bifunctor overlap with Arrow.<br>
> This actually means that they are a drop-in replacement for the commonly<br>
> suggested misuse of Arrow.<br>
><br>
> None of the dependencies of the bifunctors package are needed by the<br>
> modules in question. They are used for other modules, or as part of an<br>
> arbitrary decision of where to put an instance. For example, the tagged<br>
> dependency is used to give instances for Tagged, but these could easily be<br>
> moved into the tagged package if base were to adopt these classes.<br>
<br>
</div></div>+1, these are low-cost abstractions that definitely could use some more<br>
exposure and love, and with the 7.10 change in particular moving around<br>
the Applicative/Monad functions either way, it seems like a good time to<br>
refactor the Foldable/Traversable stuff and bring this in.<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</blockquote></div><br></div>