The previous discussion about methods on Either had some mention of adding bifunctors to base, but no one wrote up the details
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
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:
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
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