Restructure arrow and functor package.

[kailuowang]

1. move arrow to a separate module.
2. Move Profunctor and Strong to this module arrow
3. Move Bifunctor, Invariant and Contravariant to core

[kailuowang]

Please vote if you, like me, think it's mostly bikeshedding. But if you have stronger feeling to put down, please do, it will be helpful for sure.

[tpolecat]

If you agree with my organizing principle for the infographic the outliers are pretty evident I think.

[kailuowang]

looks like the decision can be made. I am moving this issue to "ready"

[kailuowang]

working on a PR.

[kailuowang]

arrow.FunctionK depends on cats.core, I incline to keep it in cats.core but it means that I need to move it to the cats root package. cc @sellout. Speaking of FunctionK its documentation is in the data types section, but I am not sure if that's accurate.

[sellout]

@kailuowang Having FunctionK in core sounds good to me.

[LukaJCB]

I think adding it to data does make some sense, as we have mostly type classes in cats . Don't have any strong opinion either way though.

[kailuowang]

the part I am not sure about is if FunctionK is a data type. Anyway moving arrow to a module is more complicated than I thought, since Category and Compose depends on SemigroupK and MonoidK, so more triage needed for that one. I'll submit one PR for restructuring the functor package first.

[LukaJCB]

Well, I'd say it's as much a data type as Kleisli and cokleisli, no? I think we could put everything that's not a type class into data :D

[sellout]

@kailuowang

1. I think having FunctionK in core/data is the right place
2. It should be fine for the arrow module to depend on the core module, no?

But yes, get rid of functor first 👍🏾

[kailuowang]

If I am not mistaken, Core depends on arrow, so circular intermodule dependency? I am okay with functionK going too data

[sellout]

@kailuowang Ah, yeah – it looks like the syntax stuff depends on arrow. That should be pulled out too if arrow is a separate module. But then I guess we’d have cats.arrow.implicits?

It’d be good to rethink the relegation of implicit conversions to their own packages. SlamData did at least a couple experiments where we eliminated the wildcard imports, and it had no noticeable effect on compilation time.

[kailuowang]

Kleisli, Cokleisli and As have instances of type classes in arrow. They also use it to get the MonoidK and SemigroupK instance from their algebraK. (hence the cycle)
If we actually do get rid off MonoidK and SemigroupK with newtype, then this problem might be solved, since algebraK is the only dependency from arrow to core.

[sellout]

@kailuowang Thanks for the clear explanation. Yeah, I almost mentioned the newtype thing (which am also in favor of).

[kailuowang]

@sellout , just realized that you are okay with the arrow module depending on the core module, what is your incentive to move it out of core again?

[LukaJCB]

I think this can be closed now, right? :)