Hi folks, is there support to create custom instances of Monads? Is that done using the meta package...

# arrow

[Daniel Berg]

Hi folks, is there support to create custom instances of Monads? Is that done using the meta package?

[stojan]

https://kotlinlang.slack.com/archives/C5UPMM0A0/p1638447487267000

HKTs are not supported at the moment, that might be revisited in the future with meta (see the linked thing in the reply)

[raulraja]

Hi @Daniel Berg, what Stojan said if what you are trying to achieve is an encoding based on higher kinded types. On the other hand if you just want to see how bind is implemented for a type it looks like this https://github.com/arrow-kt/arrow/blob/a582273dacbbd8ae52b1acb52253b025720f5877/ar[…]ow-core/src/commonMain/kotlin/arrow/core/computations/either.kt

[raulraja]

Here is how Either is exposed as monad bind. An impl of a monad in Arrow is just being able to implement:

suspend fun <A> F<A>.bind(): A

where F is a type like Either, Option or others.

[raulraja]

this is true for most monads except List, Stream and in general multishot ones that require a different style like yield, emit.

[Daniel Berg]

Hi @raulraja, yeah, that’s what I was trying to do. I think I played with it in version 0.10x but couldn’t find more information in version 1.0. I was planning to implement a monad for one of our types, and then a monad transformer with Either but scratched that.

[Daniel Berg]

After looking at how the “do-notation” behind either (either.eager) works it was easy to get the ball rolling.

[Daniel Berg]

Btw, I end up implementing a poor man’s version of Either3 which solved a few use cases at work. Any interest of adding Either3 to arrow?

[Daniel Berg]

We type alias a pinned version of Either with the Left with our own error data structure which works for the majority of use cases. But every now and then we want to short circuit the continuation based on error or a different value. Either3 did a fine job. Not sure if anyone else would benefit.

[raulraja]

@Daniel Berg that is an interesting structure, the issue is that if Kotlin introduces union types then you can just use those in the left side instead of having N arity Eithers which result in a lot of garbage since its type now also needs impls map, flatMap, bind etc. I think EitherN would be great as a side library until we get union types but since arrow core tries to stay close to the lang we don’t want to link there against types that may become deprecated because of lang features.

[raulraja]

If you release this a side lib that is something we could promote for whomever had that use case, In practice most people today would use a sealed structure in the left with multiple cases

[Daniel Berg]

I hear you. It makes sense. Good point making an external lib as well. I'll work on it. Thanks @raulraja