Hey! Is there something smooth in Arrow that transforms

List<Either<Error,Success>>

into

Either<Error, List<Success>>

?

`traverse`https://arrow-kt.io/docs/apidocs/arrow-core/arrow.core/#1746636802%2FFunctions%2F1495421781

Ah! Thx! ⭐

Also

sequence

https://arrow-kt.io/docs/apidocs/arrow-core/arrow.core/#108136395%2FFunctions%2F1495421781

when in doubt :trollface:

🤔

with that bot, the answer is always

traverse

😄

Seems like a good point to get some feedback on this 😄 We're thinking of removing this entirely in favor of the DSL, so

either { map { it.bind() } }

if you're not already within

either { }

and otherwise just

map { it.bind() }

.

I would keep it.... nullable types also have

mapNotNull {}

and this is similar 🙂 also

mapNotNull

is basically

map {}.filterNotNull()

but it's common enough

Looking at

mapNotNull

makes me think of

mapNotLeft

but that's a horrible name 😂 The semantics of

mapNotNull

are quite different though, since it doesn't short-circuit but it filters.

ah.... good point 😄

traverse

for

null

!=

mapNotNull

otherwise

mapNotNull

should return

List<A>?

anyway... general point still stands.... just because it's easily derived it doesn't mean it shouldn't exist 🙂 especially if it's commonly used but if reducing API surface is improntant... maybe remove just sequence and keep traverse 🙂

Keeping it won't impact API surface too much actually... 🤔 So maybe we should be less drastic with cutting the API. We can switch the implementation to

either { }

without affecting performance and that way it'll be easy to understand on jump to definition. I think flattening

Validated

with

Either

will give most benefit in API surface already. Albeit

traverse

for

Validated

will be now named

mapOrAccumulate

with

bind()

syntax...

I am aware of

Validated

merging with

Either

, I think I was part of the initial discussion here on slack..... IMHO that's a very good thing.... killing some legacy because of typeclasses 😄 I am not familiar with the specifics tho 🙂

As always I am always looking for feedback 😁 If you have some time, and/or have feedback please let us know. You can find all details on the changes here: • https://github.com/arrow-kt/arrow/pull/2795#issuecomment-1328864003 • Small subsequent PR: https://github.com/arrow-kt/arrow/pull/2892

Hi @simon.vergauwen, I know what happens when seeing a

traverse

or

sequence

in the code. If you replace such functions with DSL, I must “parse” DSL to determine what the code does. Is it

traverse

or

sequence

, or maybe some custom code? Or someone used an explicit parameter name, and instead of

it

there is a

document

or whatever else. The code should be easy to read. DSL does not help with that. From a newbie’s perspective, the DSL may seem a better solution, as there is less to learn. But for someone with more experience with current Arrow or FP the DSL may be an unnecessary overhead where a single word would suffice. The whole idea of programming is to hide details under a well-named abstraction.

Hey @dnowak, Thanks for the feedback ☺️ I think after this small discussion here we will keep

traverse

and

sequence

for

Either

. This feedback is very helpful! Thank you 🙏

Can you make intellij suggest traverse for stuff like map { transform(it).bind() } ?

When K2 and FIR comes out we plan to investigate building Arrow specific analysis and refactoring tools within the IDEA but we're currently waiting for such support to come to the compiler

The use of context(Raise<E>) will depend on the ergonomics of dealing with the effectscope at the edge I think.

I love the idea of having one recommend way to do things.... But unfortunately that one way is relying on experimental feature....

Can you clarify that a bit? I am not entirely sure what you mean. Do you think its currently not ergonomic?

I'm not saying it isn't ergonomic as it is, but it introduces a few new concepts

Maybe typealias into an annotation will make spring users happy :trollface:

imho, we should err on the side of being kotlin idiomatic where possible. Similarly, if we can express the problem/answer in the form of a DSL and through the DSL we can make the problem/solution more accessible(readable, ease-of-use) to everyone, we should continue to invest in DSLs. Also, we should align with the long term vision of the language where possible(e.g., context receivers).

Context receivers are pretty stable in their API right? That's what I understood from Elizarov.

It's quite hard to predict what will happen, and it'll also differ who you ask. Kotlin is growing a lot, and fast in all direction and with people coming from all kinds of different communities. Front-end (Android vs KMP vs Desktop vs Web), back-end (ktor/Vert.X vs Spring/Quarkus), and much more. I think investing in DSL style, whilst keeping the door open for traditional style gives us best of both worlds. That's why I also said above it'll be a fine line with being too drastic in shedding APIs in favor of DSL or benefitting and that is also why feedback from everyone is crucial.

Sounds reasonable