The previous discussion about methods on Either had some mention of adding bifunctors to base, but no one wrote up the details
I was implicitly leaving that to someone more qualified than me ;) This proposal looks great to me, and I agree that it is the right abstraction for functions like mapLeft and such, instead of Arrows. Still, some of the underlying assumptions made are not entirely clear to me:
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.
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. 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? I guess this is an entirely different discussion, that happend many times in the past with no relevant consensus... An additional question: would the arrow operators then be defined in terms of bifunctors? Cheers 2014-04-26 8:31 GMT+01:00 Andreas Abel <andreas.abel@ifi.lmu.de>:
I retract my bikeshedding attempt.
On 25.04.14 8:18 PM, Dan Doel wrote:
In my code, I use (<&>) from lens when I need a flipped fmap:
let ys = xs <&> \x -> ...
and do use Applicative for.
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.
-- Andreas Abel <>< Du bist der geliebte Mensch.
andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries