I'm looking at doing more work in Kotlin Multi-pla...

# arrow

[Neil Miller]

I'm looking at doing more work in Kotlin Multi-platfom. We've been using Vavr a lot, and Arrow is a natural replacement for a lot of that, but we'd really miss Vavr's true immutable collections. Is there any interest is a Kotlin port of Vavr's immutable collections becoming part of Arrow? (I'm aware of kotlinx.collections.immutable, but not a fan of some of the choices they've made)

[simon.vergauwen]

Hey @Neil Miller,

We've thought about such things in the past, but it's too much work and maintenance for the current group of maintainers. Also, none of us have the right knowledge to build solid -and fast implementations for such immutable collection types.

It's a bit of a controversial topic within the Kotlin community though 😄 Are you encountering issues with read-only lists, or are you using immutable collections for certain performance trade-offs?

[simon.vergauwen]

I tried KotlinX Immutable Collections for a little bit a long time ago, but was not convinced by their APIs. I've been successfully using read-only lists since then.

[Stylianos Gakis]

Just out of pure curiosity, what is it about kotlinx immutable APIs that felt off?
I wonder since it seems like it’ll be the de-facto way to pass immutable collections inside composable functions since it enables some performance improvements there that normal List doesn’t give so I get to use it lately.

[simon.vergauwen]

For me it's been like 5 or 6 years ago that I tried KotlinX Immutable Collections.

First thing that immediately felt "off" for me, compared to i.e. Scala was that Kotlin seems to favor the read-only List. And all operations are build around it, so it easily becomes a toXXX conversion fest all over the codebase 😭

On the flip-side, it offers us seamless inter-op with Java..

Of course it heavily depends on the case. For performance reasons in Compose it makes a lot of sense, but you could potentially just to toImmutableList at the edge where you put it into Compose, right?

[simon.vergauwen]

For library development it really doesn't make sense to include this extra depenendency.

[Stylianos Gakis]

Right, it’s true in the little I’ve played with it I had to always turn it back into toPersistentList() after I was done making some maps etc on it. And yes it worked to turn it into a persistent one at the edge just for compose, which is what I did in the little I’ve played with it.
Would it help if all the collection operators were copied to persist the ImmutableCollection type? Or if not how would you envision a proper version of this? Never tried Scala so can’t relate with that unfortunately

[raulraja]

I think immutable collections would be nice as a side lib for those wanting the feature in specific use cases. In general we would not encode arrow's List, Set's, maps or operations like traverse as immutable collections. As Simon said it would require conversion methods. In Scala it's the same issue, Scala bundles in the std lib it's own collections but any time you want to go to java and back you need to add explicit calls or a set of implicit conversions to make it happen. https://docs.scala-lang.org/overviews/collections/conversions-between-java-and-scala-collections.html

[Stylianos Gakis]

Right, so in general there is no “good” solution to this if I understand correctly, we simply have to add the explicit conversions everywhere. If this is the case, why would the kotlinx not be considered a library with a good API?

[simon.vergauwen]

There is also a large section on this in the value-classes (immutable data) KEEP, https://github.com/Kotlin/KEEP/blob/master/notes/value-classes.md#read-only-collections-vs-immutable-collections.

Not sure if having language support could also improve these things 🤔 @raulraja Could something like Scala's match types improve the return type issue?

[simon.vergauwen]

If this is the case, why would the kotlinx not be considered a library with a good API?

I would say that the API itself is fine, it might be a bit unconventional for people used to immutable collections though. Especially the mutate builder 😄 but it's very much in the Kotlin spirit so I think it's probably a good thing. Accepting the current status-quo is not better for sure.

A solution such as the KEEP that could potentially reduce, or completely eliminate the need for many conversions would be great though.

[raulraja]

Could something like Scala's match types improve the return type issue?

yes if Kotlin had a form of transparent inline you could hide the implementations, but it's probably overkill.
Also it could be hidden with automatic implicit conversions.
Beside the ergonomics this would not be a great solution either.
The real problem is the community already depends on the collections in the std lib.
It's the same as if the std lib included Either, it would not make sense for Arrow to include it even if our Either was more complete. We'd choose to try to make better whatever is already in the std lib and in use by the rest of the community.

[Satyam Agarwal]

First thing that immediately felt "off" for me, compared to i.e. Scala was that Kotlin seems to favor the read-only List. And all operations are build around it, so it easily becomes a toXXX conversion fest all over the codebase 😭

Same applies to NonEmptyList in arrow.
I love this data type but it's so tedious to convert it back and forth.

[Neil Miller]

Sorry to be slow to reply, there was a lot to dig into here. 🙂
1. Background: we're working on an old complex app that uses immutable state as a core design choice. The app started in Java, the Vavr decision was made in that timeframe as Java's immutable story is even worse.
2. We have seen issues where proper "hygiene" was not followed when using Kotlin read-only collections. Sometimes the leak is subtle. An API that enforces immutability is therefore desirable.
3. What I don't like about kotlinx.collections.immutable:
a. The inclusion of the adapters package - allowing mutable data to masquerade as immutable is dangerous and its inclusion in the main library is a poor decision. I get the desire, but it should be an add-on.
b. More complex data structures are the default, rather than by request
c. Possibly more, I stopped evaluating it based on the above.

[Stylianos Gakis]

Since it's not on 1.x yet, I think it'd be a good idea to raise your concern about the adapters package not being opt-in. Then there's a chance this gets addressed for the 1.x release if the authors agree with you.

[Neil Miller]

A good idea.