<div dir="ltr"><div><div><div><div><div><div><div>> The previous discussion about methods on Either had some mention of adding bifunctors to base, but no one wrote up the details<br><br></div>I was implicitly leaving that to someone more qualified than me ;)<br>




<br></div>This proposal looks great to me, and I agree that it is the right abstraction for functions like mapLeft and such, instead of Arrows.<br></div>Still, some of the underlying assumptions made are not entirely clear to me:<br>




<br>> If someone goes into the documentation for Data.Either looking for a way
 to map both parameters, <br>> they will not, of course, be directed to the 
bifunctors package, even though it provides a good means of doing what 
they want.<br><br></div>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.<br>



<br>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?<br>



</div>I guess this is an entirely different discussion, that happend many times in the past with no relevant consensus...<br><br></div>An additional question: would the arrow operators then be defined in terms of bifunctors?<br>


<br></div>Cheers<br><div><div><div>
<div><br></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-26 8:31 GMT+01:00 Andreas Abel <span dir="ltr"><<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a>></span>:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I retract my bikeshedding attempt.<br>
<br>
On 25.04.14 8:18 PM, Dan Doel wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
​In my code, I use (<&>) from lens when I need a flipped fmap:<br>
<br>
     let ys = xs <&> \x -> ...<br>
<br>
and do use Applicative for.<br>
</blockquote>
<br>
Maybe & and <&> become standard at some point, and then I am maybe fine to use them.  Only that "<&>", unlike "for", does not evoke any association to iteration in my brain.<div class="">

<br>
<br>
-- <br>
Andreas Abel  <><      Du bist der geliebte Mensch.<br>
<br>
</div><a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a><br>
<a href="http://www2.tcs.ifi.lmu.de/~abel/" target="_blank">http://www2.tcs.ifi.lmu.de/~<u></u>abel/</a><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>