Hello <@U4UGS5FC7> Has something came up in terms ...

# arrow

[Filip Piechowski]

Hello @raulraja Has something came up in terms of possibilities for higher kinded types since that last time?

[simon.vergauwen]

We've moved completely away from that, since then we've found other solutions that are more elegant, and idiomatic in Kotlin.

Higher Kinded Types, are often used for abstractions such as Functor, Applicative, Monad, etc. We've found that working with suspend, and context based DSLs works much nicer.

For example: Kleisli[EitherT[IO, E, ?], R, A] can be replaced with

context(_: Raise<E>)
suspend R.function(): A = TODO()

So we don't need monad transformers, or flatMap to compose these behaviors. Instead we can still rely on simple function composition.

This is very in spirit with nullable types, A? vs Option<A> and the already mentioned suspend vs IO. While this doesn't cover 100% of the use-cases, we feel it covers 99% of them and so far every problem we've encountered we've always were able to encode it as a context. Other examples are: SagaScope, ResourceScope, AutoCloseScope, and FlowCollector, ProducerScope, etc are also other great example from KotlinX Coroutines.

While it might be possible in the future to achieve with compiler plugins, I'm afraid it wouldn't fit nicely into the Kotlin ecosystem.

[simon.vergauwen]

As a side question, what is your use-case?

[Filip Piechowski]

i was just curious if it’s still a thing after all that time

[raulraja]

I agree with Simon. Additionally kinds only play a role when defining polymorphic code that automatically receives a typeclass like implementation like the ones Simon listed.

For Kotlin to have kinds there would need to be changes to typechecking and resolution in the compiler + a form of automatic injection through context receivers or similar and a system to determine if instances injected are scoped or global. I'm not seeing any of these as a focus or interest in current's Kotlin direction.

@Alejandro Serrano.Mena is working in the compiler and context receivers area and he may be able to provide more background on why kinds may make sense or not in Kotlin given the current direction.