A modern programming language that makes developers happier.

kotlinlang

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

<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)

Hi <@U011L9P17H6>, 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/arrow-libs/core/arrow-core/src/commonMain/kotlin/arrow/core/computations/either.kt|https://github.com/arrow-kt/arrow/blob/a582273dacbbd8ae52b1acb52253b025720f5877/ar[…]ow-core/src/commonMain/kotlin/arrow/core/computations/either.kt>

Here is how Either is exposed as monad bind. An impl of a monad in Arrow is just being able to implement:
```suspend fun &lt;A&gt; F&lt;A&gt;.bind(): A```
where F is a type like Either, Option or others.

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

Hi <@U4UGS5FC7>, 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.

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

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?

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.

<@U011L9P17H6> 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.

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

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