Multiple things are prefixed withBi- meaning different things.

[mgttlinger]

We have a Bimonad where the prefix means that it is a Monad and a Comonad. We also have things like Bifunctor, Bifoldable and Bitraverse where the prefix expresses that it is about types with two type parameters instead of one.

In #30 this has been brought up already and it was suggested to rename Bimonad to DualMonad or SelfDualMonad by @fthomas and @non. DualedMonad was also suggested. On gitter the discussion was revived recently and I suggested keeping Bimonad as nlab agrees with the naming (https://ncatlab.org/nlab/show/Hopf+monad)

Thus, we might define a bimonad to be an endofunctor H H equipped with the structure of both a monad and a comonad, ...

I suggested to rename the other interfaces to a Bin- prefix to denote that their type constructors are binary but that would raise the issue again once we want interfaces for types with three parameters. @tpolecat suggested to change them to Functor2, Functor3, ... which would leave those options open for the future and should be familiar to a Scala programmer given that e.g. the Function types use the same "convention"

[milessabin]

In shapeless I've adopted the convention of using 1, 2, 3 etc. suffixes to convey kinds * -> *, * -> * -> *, * -> * -> * -> * etc. so there's also that precedent.

[mgttlinger]

What would functions like bimap, bifoldLeft, ... be renamed to? map2, foldLeft2?

[non]

We are currently using map2 for the cartesian builder syntax:

val fa: F[A] = ...
val fb: F[B] = ...
def fn(a: A, b: B): C = ...
(fa, fb).map2 { case (a, b) => fn(a, b) }

That said, I'm fine with using numeric suffixes. We might need to using different names for these methods, or for the cartesian builders, but that's OK. I'm not sure we'll ever need to support 3+ here (and a Tri or Trin suffix would be OK), so I think we have options.

[mgttlinger]

@a-reisberg Said that Tri- is also already taken for something already: https://gitter.im/typelevel/cats?at=57b603e2bb6fad403ce744c1

[a-reisberg]

Tri-algebras, as @sellout mentioned right before my rephrase (sorry, I don't know how to make a link...), essentially live in higher categories, so I don't think we have any use for them (at least for a while? :) ).

At the same time though, I want to chime in that I do like the suffice n better than these bi-, tri- etc. In most mathematical terminologies, bi- usually means that something has both a "something" and a "co-something" (like bimonad, bialgebras). So already, this tri-algebra thing is already an abuse of language (a tri-algebra is a co-algebra with 2 extra algebra structures compatible in some way).

[mgttlinger]

So if people are in favour of the numeric suffices I can put together a PR with the changes.

[non]

@mgttlinger This sounds like the way to go. Thanks!

Do people think it's worth providing compatibility aliases for things like Bifoldable (maybe with a deprecation warning) or just go straight to the new names?

[mgttlinger]

PR: #1334

[mgttlinger]

How should the map$arity of cartesian be changed? cmap$arity?

[mgttlinger]

I chose mapA$arity as tupleA2 was already there in the boilerplate.

[kailuowang]

I'm more sympathetic toward the option 1 mentioned in this comment by @non Edit: I changed my mind, see comment below

Namely

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-".

[kailuowang]

It seems to me that the name Bifunctor in category theory is more canonical than Bimonad that was introduced later. So if we want to consolidate the meaning of "Bi" I am now more leaning towards keeping Bifunctor, but I am totally fine with keeping it as is.

[mgttlinger]

I am by now strongly in favour of keeping Bimonad because I know of no example where the Bi prefix does not in some sense mean back-and-forth in math. (e.g. Bijection, Bisimulation, (Bimonad)) Also the notion of numeric suffices would allign with the stdlib where a TupleX/FunctionX has the same kind as or FunctorX.

[kailuowang]

@mgttlinger I just saw this on the bifunctor entry on nLab:

Outside of certain computer science contexts, it is not clear that the term ‘bifunctor’ is used frequently nowadays, even for the sense of a functor of two variables. It is used more frequently in older texts. ↩

So CS people stuck with a term that is already out of fashion in math (probably for good reasons.) I don't have a strong opinion over what we shall do about it in cats. I agree with you that rename Bimonad is probably backward. How strongly are you against keeping Bifunctor (and Bitravse etc) ? I mean renaming to Functor2 will give people searching for Bifunctor a hard time.

[mgttlinger]

How viable would it be to have those things named with numeric suffices but have a type alias as Bifunctor etc?

[kailuowang]

That might be a good idea.

[mgttlinger]

The only downside I see is that if one day we need the aliased name for something it would become odd.

[peterneyens]

Depending on what we end up doing, we might have to come up with a new name for Traverse1 (#1611).
Having Traverse, Traverse1 and Traverse2 would be even more confusing.

[LukaJCB]

Maybe we could rename Traverse1 to NonEmptyTraverse?

[mgttlinger]

Yesterday I was able to clarify how the name Bifunctor makes sense. The bi- prefix on things like bimonads, bialgebras etc is a different bi- prefix than the one on the bi-functor. The later is similar to the bi- on bilinear operations.

[larsrh]

Closing this one for inactivity. (Also it's too late to change anything like that now.)