flatMap about kotlin-result

[Ravirael]

You mention the extension function for Kotlin's Mapclass. However there is also a version for Iterable with signature fun <T, R> Iterable<T>.flatMap(transform: (T) -> Iterable<R>): List<R> . As you can see this is really similar to your andThen by parameters and return type. Both functions are defined for some Monad<T> take function (T) -> Monad<R> and return Monad<R>, that's why this name seems reasonable for me.

Also in this alternative library that operation is called flatMap.

Of course using Elm's convention also makes sense.

[Ravirael]

Yes, that's it. Thank you!

[Ravirael]

Well, there also is a flatMap method in Java's Optional and similary flatMap in Scala's Option. They are equivalent to your andThen as much as they can be!

I agree that the name itself is confusing, however it somehow shows a relationship with map. Still I believe this is a common name for this type of operation in Java's world.

[michaelbull]

Do you mean andThen?

[michaelbull]

I don't see how that's semantically a flatMap, when you look at Kotlin's definition of a flatMap (applies a function to every element of a map, returning a single list of the elements). The naming andThen comes from Elm's andThen.

Anyway glad to help, let me know if there is anything else missing.

[michaelbull]

The flatMap on an Iterable<T> conforms to Kotlin's definition of flatMap as it returns a single List<R> of elements yielded from the results of the transform function being applied to each element (T) in the Iterable<T>. The signature for andThen doesn't operate on an Iterable nor a Map - and does not yield a List of Results, just a single Result. I think the naming in that library is misleading.

[michaelbull]

I think that's a stronger argument, however I still feel uneasy given Kotlin's definition of flatMap. Happy to consider adding flatMap as an alias of andThen on the back of your points if people think it's necessary.

[kevinherron]

FWIW, I also scratched my head looking for the missing flatMap function.

I think it's okay for flatMap to have a slightly different definition when applied to an Iterable or Collection as when applied to something like Result (or Either, or Option, etc...).

It's the same way in Scala land.

flatMap is the Monad bind operation, and the Monad instance for an Iterable or Collection is different than for Result, yeah?

[michaelbull]

Does Scala have a Result type with flatMap on it? I'm under the impression that its existence on the Optional class is due to the fact that Optional can be argued as a unary "collection", which is much harder to argue for in the Result class.

Not to mention other functional languages have opted for andThen as their naming scheme for this method:

• Rust: Result.and_then
• Elm: Result.andThen

If this is an issue for you due to some form of naming conflict, then you could always use import as to alias andThen to flatMap.

[kevinherron]

It has Either, which is basically the same thing (except it's right-biased, whereas your Result is left-biased because it names the left and right as value/error).

I'm not disputing andThen as an appropriate name, but this operation is fundamentally flatMap. If anything, andThen should alias flatMap.

[michaelbull]

On the back of flatMap existing on Scala's Either, I've added an alias function named andThen to Map.kt (44a4467).

Thanks to both of you for your input.