How will Context Receivers (<https://github.com/Ko...

# arrow

[CLOVIS]

How will Context Receivers (https://github.com/Kotlin/KEEP/blob/context-receivers/proposals/context-receivers.md) impact Arrow? In particular, they mention Monoid as a use case, and that looks really close to what typeclasses were trying to achieve

[raulraja]

Context receivers among others came after keep87 and they all have a piece of type classes and I think all as keep 87 were influenced by type classes. We are looking forward to context receivers. The missing piece there that type classes has and this doesn’t is actually creating the instance that satisfies your contextual functions to be able to invoke them without manually instantiating them. Context receivers will allows us to encode in arrow and other places functions whose context is in things like the either effect block so you don’t manually need to open the block and can use the bind syntax directly. Like that many other places we expect to become more ergonomic.
Still for cases like:

context(Monoid<T>) // T is used
fun <T> List<T>.sum(): T = ...

This does not actually take care of pairing Monoid<T> with say the Int monoid instance implicitly, you are still responsible AFAIK to construct that manually so you can invoke this function in the right scope.

[CLOVIS]

So essentially the with() part is still mandatory

I guess it will become much easier (and idiomatic) for Arrow Meta to provide the implicit implementation when this is in the language, because then Meta-compiled frameworks will look from the outside as normal idiomatic Kotlin

[raulraja]

yes we are repurposing injection with @Given to allow any user to use their own annotations that are contextual to their own domain name spaces. https://github.com/arrow-kt/arrow-meta/pull/827 This way implicit injection is not confusing as it’s scoped to what you care only. In Arrow it may be @Given or @Instance but in other places it can be @Config, @Codec or whatever injectable domain you are dealing with.