Hei ! I noticed that Arrow has deprecated few apis in 1.1.5 that was released. I understand that you want to limit the surface of the api. But the library have some great methods now being being deprecated. Without having more context or read Proposals in 2.0.0 roadmap, I think the idea is to be more align with what kotlin standard libraries provide and recommend ? Take

filterOrElse

for example. Me and few in my team are fan of function chains. we feel each function denotes what kind of transformation is being applied to the passed data. deprecating such functions force us to push conditions in flatmap or use bind. Looks like we will have to eventually start using either block even for small programs. My question really is, that as library provider, is there a huge overhead for Arrow in maintaining such util functions on the data types like Either and Option ?

Hi Satyam, there is no huge overhead but rather trying to align with the essence of what we think can do best in Kotlin's and little more. We are actually trying to get further than removing the

indirect

methods when context receivers are stable in kotlin. In that case you would be able to declare programs with

context(Raise<String>)
fun foo(): Int = raise("oops")

Entirely eliminating the need to have either blocks or function chains. Just regular code that raises typed values where required. This doesn't mean Either will disappear or that things like

filterOrElse

may make sense for convenience or not. What we do not want to do is maintain a large library of combinators for indirect function style because in Kotlin we don't need to with suspension and things like context receivers, bind or either blocks. Either will become one of the target types you can evaluate a program that uses the

context(Raise<A>)

.

I understand. I am not saying that such indirect functions should not be deprecated. Nothing that can’t be accommodated by using different methods like raise, shift, flatmaps etc. Been using the library since 0.6.0, and have been adapting to the different patterns introduced since then by the library. So, there is an obvious shift I have to adapt again, specifically around context receivers, and the new patterns arrow library is bringing by being more inline with kotlin. Just had to ask to understand the thought process of the maintainers, have seen this library come a long way 😊 :arrow: ❤️

Still for cases where

either + bind

or context receivers turns out more verbose we think it's fine to keep the additional operations. We did our best to think about each case but maybe we missed a few where it makes sense to preserve and that is possible. Ideally we don't end up with a big API but we can evaluate every operator on a case by case basis and decide with the community if any should remain before 2.0. from the deprecated ones.

For sure. We do use either blocks where we have many side effects and the order we need to use the evaluated values is not too down. And when operations naturally falls in top down order we use function chains. So we haven’t seen that either blocks become bloated. And even if they do, usually it indicates code smell, and we extract operations to a new method.

Only

filterOrElse

and

filterOrOther

are deprecated? 🤔 The other ones you mentioned are staying, or where renamed to more Kotlin Std naming. I.e. we had a vote on

tap

and

tapLeft

and those got renamed to

onRight

and

onLeft

.

I felt exactly the same. The deprecated function like leftIfNull on Either and such make my code a LOT more unreadable and full of noise characters for ?: , .? right / left and flatMaps. I doubt this will make things easier to comprehend and force me to write my own extension functions again making this easy to read. So Arrow removes such functions and many people write exactly the same helper extension functions... sad...

Hey @Olaf Gottschalk, Not sure if you saw my reply on your comment in the PR. This deprecations were not made with

flatMap

and

?

in mind, to the contrary. If this API is in such high demand, we can always keep it around. We've asked for feedback in many places, and only got positive reactions before this release.

Sorry Simon, did not see it yet. 🙂 Well, what did you have in mind then? I mean, I updated to 1.1.5 and had like 40 deprecation warnings of exactly that kind. And the quick fix offered for leftIfNull is a flatMap with b?.right() ?: default().left - so you apply that. Is there a better way to express that? If so, would it be possible to put that into the ReplaceWith statement? What would you recommend?

We consider the following code to be Arrow & Kotlin idiomatic. It leverages both the Arrow DSL, and Kotlin smart casting to offer an elegant and Kotlin idiomatic API.

either {
  val b: B? = bind()
  ensureNotNull(b) { default() }
  // b is smart-casted to non-null
}

Sadly

ReplaceWith

doesn't allow this kind of deprecations 😞

I've used the either DSL but found it rather bloated if I could have done it with a simple function chaining... maybe a personal preference? Also, either DSL makes me go back to code blocks - which I try to avoid almost everywhere in favor of expressions

Also, either DSL makes me go back to code blocks - which I try to avoid almost everywhere in favor of expressions

We've had to opposite experience, and same for everyone we received feedback from prior to merging this PR. Your non-functional colleagues find

flatMap

more idiomatic than

bind

? 🤯 That's the first time I ever heard that. Similarly for code blocks, rather than FP based chaining. DSL blocks are equivalent to what

suspend

does for concurrency. You can however completely avoid

bind

if you want by using context based code, as shown above with the extension function. Context receivers will open the door to this even more.

Interesting... I really need to get more into discussions here. Yes, explaining people what map and flatMap do is somehow easier than explaining a DSL and a function bind() in my experience...

There is also a non-suspend version of this DSL, but in reality Kotlin Coroutines doesn't apply concurrency. It's just a mechanism the compiler provides. The most popular, or best known, use-case is concurrency but both are unrelated.

I know that.. 😉 It's less experienced programmers that get problems when they see "suspend" and don't understand why....

In FP people typically spit code as much as possible, and most functions are simple expressions. I also love them. The DSL provides an alternative to Scala's for-comprehensions or Haskells do-notation. In both those languages

flatMap

is also not really loved and the languages offer these alternatives to avoid them.

So, here as an example, I had this:

There is also

either.eager { }

which doesn't require suspension.

is using either.eager giving me a performance penalty?

There is no performance penalty for the DSLs, they're much faster than chaining functions like that.

that's totally crazy - but cool. Maybe that is something to express more?

They still use Kotlin Coroutines under the hood, but without allowing concurrency. So all optimisation from the Kotlin compiler are still in place. Similar to

Sequence

from Kotlin Std. The documentation is due an overhaul/improvement, but it's something we've planned as part of the 2.0 work.

Do you have an advice in my either DSL block? So first, I use

ensureNotNull

for my check of null - but then I need to call legacy code with catch. Should I use

Either.catch { ... }.bind()

directly?

You can do a couple things, use

bind

like you show there. Directly calling

Either.catch

in the

either.eager { }

block, or extracting it to a separate function.

fun myFunction(): Either<Throwable, A> =
  Either.catch { ... }

either.eager {
  myFunction().bind()
  Either.catch { ... }.bind()
}

Yep. My problem was the left type had to be mapped first before calling bind. Otherwise the compiler chose the "wrong" bind of Either

Yes, we have one prototyped but it's not yet been released. It has kind-of a funky signature but it supports all use-cases. Similar to

Flow#catch

. So it allows you to transform an error to a new error, but also provide a fallback value.

fun sideEffect(): Int = ...

either.eager {
  val i = catch(
    { sideEffect() }
   ) { t: Throwable ->
    // otherFunction(throwable).bind()
    // shift(MyError(throwable))
    fallback
  }
  ...
}

So the performance gain basically comes from less allocations of objects?

Both from avoiding allocations, and from the super efficient way the Kotlin compiler optimises Coroutines.

flatMap

requires 2 allocations, while

either.eager

only requires a single one. Within

either.eager

you can however call an infinite amount of

flatMap

without requiring additional allocations. So the benefit also depends on the code, but even in a small snippet

either.eager

is theoretically faster.

So, you said that I can avoid using left right or bind - but the bind inside the either DSL is not something to avoid, you mean "the other bind()", right?

These two functions are equivalent, but note that only 1 requires

bind

and

left()

.

fun EagerEffectScope<MyError>.x(): Int =
  shift(MyError)

fun y(): Either<MyError, Int> =
  MyError.left()

either.eager {
  x() + y().bind()
}

(For 2.0 we're considering flattening

EagerEffectScope

and

EffectScope

into

Raise

, or renaming to

EagerRaise

and

Raise

) With Kotlin's context receivers you can "free" the extension receiver by moving it to the context.

context(EagerEffectScope<MyError>)
fun x(): Int = shift(MyError)

That's cool! I also can't wait to finally get ContextReceivers...

And all utilities should be available through elegant DSL syntax, that are available for all types not just

Either

. So the same DSL is applicable everywhere, even for your own types that you might want to integrate to the DSL. This way you can also move, and combine different types inside the same DSL without having to move back -and forth between types.

@simon.vergauwen you already made me understand some things much better - I have another problem with Validations and the pattern to accumulate errors instead of failing fast. I reach the limit of 10 parameters to use zip - and I ask myself: is there also a better "DSL" way of doing that? In my case it's about config validation with a "Thing" that requires 10 parameters to be correct, all of them packed in a ValidatedNel which I then zip to call the constructor of that thing. a.zip(b, c, d, e, ... ::Thing) to construct the Thing... now there's yet one more parameter and the zip is not available for more than 10 things. Any other/better/more FP way to do this?

Hey @Olaf Gottschalk, Glad I was able to provide help ☺️ Be sure to ask any question here if you have any other doubts! Yes, this is also a common problem 😞 We plan to also explain this clearly in the docs. We choose 9 parameters as the upper limit of what we encode in Arrow but you can quite easily compose/nest multiple

zip

within each-other. Here is my answer on SO to this question 😉 https://stackoverflow.com/questions/72782045/arrow-validation-more-then-10-fields/72782420#72782420

Yeah, I learned about this Slack through JetBrains' Advent of Code channel... should have done this earlier. I am now starting to revisit all my former flatMap / left / right situations... Thanks a lot for your very kind help!

My pleasure ☺️

Morning @simon.vergauwen - I got another question. When dealing with the either effect scope of R and the thing to bind has a different left type A, this needs to be changed prior to bind() to fit into the scope. So, naturally one could do

val x = myFun().mapLeft { mapAToR(it) } .bind()

. But I also found out I could do this:

val x = attempt { myFun().bind() } catch { shift(mapAToR(it)) }

Which one would be preferred? I assume the first one would allocate at least one more Either wrapper which the second one does not?

Good morning @Olaf Gottschalk, There is not really a "preferred", Arrow still aims to facilitate both writing styles. Otherwise it would eliminate one over the other, as Kotlin Std often does. I.e. many people might prefer splitting into

fun res(): Either<E, A> = myFun().mapLeft { mapAToR(it) }

with

res().bind()

over the second one. Even though the second one can also be split,

fun EagerEffectScope<E>.res(): A = attempt { myFun().bind() } catch { shift(mapAToR(it)) }

. The second one is an higher abstraction on top of Coroutines, so the implementation is re-used for

Option

,

Ior

,

Result

and other custom types.

assume the first one would allocate at least one more Either wrapper which the second one does not?

That is correct, but that is often neglect-able in the face of network or database interactions. Arrow tries to be somewhat opinionated, but also not so much that it limits the user in how they model their code. If you're already heavily using

Either

than the first option is absolutely fine, but the second one opens the door to leverage context receivers more in the future. Note that these APIs are still a bit in flux until context receivers are completely stable, so they might change name or shape if needed.

That's great yeah. Just through this discussion my whole mindmap on Either types has now broadend to see that fun EffectScope<A>.doThis(): B is equivalent to fun doThis(): Either<A, B> but much higher abstracted because it's neither bound to Either nor uses memory objects to transport the fact that the computation might fail indicated by type A... that's awesome. For ValidatedNels with accumulating errors there is no such abstraction, right? We are stuck to using zip / valid / invalid functions?

Yes, exactly 🙌

For ValidatedNels with accumulating errors there is no such abstraction, right? We are stuck to using zip / valid / invalid functions?

We're working on this towards 2.0, I hope to include the new APIs in 1.2.0. We're thinking of flattening

Validated

into

Either

by exposing its accumulating errors APIs for

Either

, and exposing the same APIs over

EffectScope

. In the same fashion as our discussions above. Some references to see the on-going work. https://github.com/arrow-kt/arrow/pull/2892 https://github.com/arrow-kt/arrow/pull/2880 https://github.com/arrow-kt/arrow/pull/2795

What we do not want to do is maintain a large library of combinators for indirect function style because in Kotlin we don't need to with suspension and things like context receivers, bind or either blocks.

Where could I learn more about what other bigger changes are in the books? Say, for the 2.0.0. This PR was good list for some of the API changes. I am trying to get some idea on how stable the library is.

The library is stable in terms of functionality, but there is a some redundancy in the APIs which is what we're removing. Besides that, some other changes are simple renames to be more aligned with Kotlin Std naming. Or simplifications to the APIs, and encodings.

Thanks! I got a bit over 100 different deprecation warnings for upgrading one of our services. Most of these point us towards using effect scope and ultimately result in general the same level of readability. For stability I was thinking more on the current users code continuing to work as-is even at the cost to maintainer (more code, less elegant interfaces, etc). But this, I think, is more of a question of general approach the library takes into maintenance.

Maintainability of downstream projects is one of our most important priorities. We regularly ask for feedback in this channel, both on the topic of maintenance as renaming or improving current APIs. The Either API improvements for exampel were a community based discussions. Some of the renames, which can be refactored automatically through IntelliJ, were feedback input from the community and not arbitrary things the maintainers decided to do. "towards using effect scope", if this is the deprecation I have in mind a simple

find + replace

can fix all of them without breaking anything. So it's non-impactful. Which seemed like a non-impactful refactor for downstream projects. We've always included these steps in the migration guides of the release posts. https://www.47deg.com/blog/arrow-v1-01-0-release/#the-effect-runtime-2 APIs and binary will be stable in the 1.x.x, and nothing will be breaking until 2.x.x which means that you can safely rely on any 1.x.x based library without any runtime conflicts or upgrading your current codebase. We don't expect any more changes like this after 2.x.x, since we've ironed out all these improvements and API renaming together with the community in the last 3 years of 1.x.x being stable.

Hey, that's good to hear! My concern isn't about the amount of work needed for, say, these changes any such changes but more about the philosophy on how the library is developed. And your message helps with that. "Philosophy" being here where the library stands in the tongue-in-cheek continuum of: <----> JavaScript Library on making breaking changes to existing API.