Fix for #1297

[mgttlinger]

We now have the problem of two map2 methods with different signatures.

[codecov-io]

Current coverage is 91.39% (diff: 95.16%)

Merging #1334 into master will increase coverage by <.01%

@@             master      #1334   diff @@
==========================================
  Files           237        237          
  Lines          3567       3568     +1   
  Methods        3502       3504     +2   
  Messages          0          0          
  Branches         64         63     -1   
==========================================
+ Hits           3260       3261     +1   
  Misses          307        307          
  Partials          0          0          

Powered by Codecov. Last update 41d9ef8...9871ac8

[non]

Thanks @mgttlinger!

One thing I'm wondering -- is Functor2 (previously Bifunctor) more used than Applicative? In my experience I use the latter more, so I'd rather rename the former. But I might be wrong.

[mgttlinger]

tupleA2 was there already somewhere in the context of the Applicative boilerplate so I thought that would be fitting.

[mgttlinger]

Soooooo, should I change anything? Or how does this move forward?

[non]

@mgttlinger I think at this point we should get more sign-offs on the change, particularly since changing names is a breaking change. I'll try to ping folks in the channel to get them to weigh-in.

[mgttlinger]

I will fix the conflicts once it has been decided if my changes are OK at all.

[non]

So at this point here are the things on my mind, ranked in order of importance (from my point of view):

1. Ensure that syntax providing methods (e.g.map2) is not ambiguous.
2. Ensure that we don't have duplicate method names (e.g. map2) provided by syntax.
3. Distinguish bimonad from bifunctor, bifoldable, etc.

The wrinkle here is that we've introduced a .map2 syntax on tuples to replace the applicative builder syntax (i.e. |@|). So I don't think we should switch map2 to be something on Bifunctor (or Functor2) instead, since we'd have to change this syntax as well.

In the current code, we already have (1) and (2) from my point of view (there are two ways to get .map2 syntax but they are never ambiguous: one applies to F[_] values and one applies to tuples). So the changes this PR are introducing are primarily solving (3), while hopefully not making (1) or (2) worse.

I see two clear ways forward:

First, we could rename the Bi- type classes (other than Bimonad) to numeric suffixes (Functor2, Foldable2, etc.) but leave the method names alone. This means that if we added Functor3 we'd want to add a trimap method, but that seems OK to me. If we do this there is no duplication or conflation going on, and the only slightly confusing thing is remembering that type classes with "2" suffixes have methods starting in "bi-".

The other option I see is to do nothing. I don't think the possible confusion between Bimonad and Bifunctor is currently that severe, so making major breaking changes just to fix this issue might not be worth it.

I'm fine with either of those approaches. What do you all think? @mgttlinger, what is your opinion on the best way to move forward? Please let me know if I'm missing some of the motivation for these changes.

[travisbrown]

@non @mgttlinger Since it's not clear which direction we want to go here, mind if we push this to after 0.8.0?

[non]

I'm fine with putting this off until after 0.8.0 personally.

[mgttlinger]

The main motivation for those changes is that a "bi-" prefix seems to communicate that something is the thing following as well as its dual in mathematics. I'm fine with delaying that change further but I think it would definitely make sense to change those names eventually. If we can come up with a cooler name than map2 for the bimap I am happy to avoid all this renaming established methods stuff. The numeric suffices aren't terribly necessary as we probably won't need much higher type-aritys (if that's the right word; kindnesses? whatever) than two or three at max.

[mgttlinger]

Closing as this probably won't get merged and is too outdated by now