Deprecates Kind and its associated type class types.

[raulraja]

This PR deprecates the Kind interface, its aliases and all type classes that have kinded types.

After a few years with emulated kinds in arrow the user burden and proliferation of fix all over user code has made us decide and push toward removing this emulation from the library. We decided to go in favor of concrete member and extensions that offer the same functionality but better ergonomics.

For this reason Kind polymorphism is no longer supported but effect and other forms of polymorphism are available through basic type classes, fun interface and the ability for users to define operators in computation builders such as monad invoke.

Other PRs like #272 are being done for each data type extensions and members remaining in Arrow core.

[1Jajen1]

Are we still continuing a kind based api somewhere? Kinds have their fair share of uses in some more obscure but nevertheless useful parts of fp, for example some recursion schemes need it. If not I'll just port them somewhere else anyway at some point, just wanted to know before committing to it^^

[raulraja]

@1Jajen1 The current plan is to deprecate kinds across the board because it forces users into fix() or worst map { it.fix() }.fix() as the indirection increases. This is the only reason to deprecate kinds, the inability to have them work unless we introduce a plugin like proofs. Since we don't want to do that mandatory and we can't given IR is not stable we have no way to preserve kinds and keep the library Kotlin idiomatic. If any parts of Arrow needs kinds internally it's fine to keep them wherever but we agreed in kinds not having enough benefit for users to impose on them having to call fix(). Also 3rd party data types can't be kinded without wrapped into type with an additional allocation cost like ListK. I'm not sure in cases like Recursion schemes if it makes sense without kinds or what parts of it are useful in the concrete data types we have beside fold but if it makes sense to keep it there it can be moved internally to that library. AQL and others in the incubator will be discontinued until we have a time to revisit them after 1.0 and see if they still make sense.

[1Jajen1]

@1Jajen1 The current plan is to deprecate kinds across the board because it forces uses into fix() or worst map { it.fix() }.fix() as the indirection increases. This is the only reason to deprecate kinds, the inability to have them work unless we introduce a plugin like proofs. Since we don't want to do that mandatory and we can't given IR is not stables we have no way to preserve kinds. If any parts of Arrow needs kinds internally it's fine to keep them wherever but we agreed in kinds not having enough benefit for users to impose on them having to call fix(). Also 3rd party data types can't be kinded without wrapped into type with an additional allocation cost like ListK. I'm not sure in cases like Recursion schemes if it makes sense without kinds or what parts of it are useful in the concrete data types we have beside fold.

Yes I get why kinds are being removed, tho there are patterns that cannot be expressed without them and I am fine with not having those patterns around core. Recursion schemes need kinds in the api and free like structures are easier to model with them as well (thinking of Free selectives/Free applicatives here. Use case being statically optimized data fetching, parsing and such). So this can go two ways I think: Either we keep kinds in a with meta only section of arrow or I'll at some point maintain a lib with that myself, tbh I don't really have any opinion on what is better, just asking for some thoughts on this. I in no way think that we should offer a kind based api as we have atm, just the bits needed to make recursion schemes and other use cases usable.

[raulraja]

@1Jajen1 Happy new year!
If the kind implementation can be contained in Arrow for internal usage without being published as user API I think it's fine to keep in the module or a separate internal module. I'm not sure how the recursion schemes lib could offer it's api unkinded and still make sense but if there is a place we can keep it wherever you think makes most sense. We have no use for kinds anywhere else at the moment once we port the functions as Simon did in #276, the only concern is if it the kind type partially applied or fix would show in user apis.

[i-walker]

This would need a deprecation cycle, to not break dependent API's like in Arrow Fx. Unless we want to delete it from core and move it to Fx.
So far only fx, fx-rx2 need this operator
cc @nomisRev , @raulraja

[nomisRev]

This should go through a deprecation cycle in core directly. Moving it to Arrow Fx would still be a breaking change.

[danimontoya]

🙌 🙌