Hi, any sense on how far is

0.11.0-SNAPSHOT

from being stable?

I just learned about Kotlin's

where

, and that sounds so much perfect for combining typeclasses https://kotlinlang.org/docs/reference/generics.html#upper-bounds

Got an update that 0.11.0 is launched. Is release process complete ?

Cannot build with arrow. Here's my build.gradle:

plugins {
    id 'org.jetbrains.kotlin.jvm' version '1.4.0'
}

group 'org.example'
version '1.0-SNAPSHOT'

repositories {
    mavenCentral()
    jcenter()
    maven { url "<https://dl.bintray.com/arrow-kt/arrow-kt/>" }
    maven { url "<https://oss.jfrog.org/artifactory/oss-snapshot-local/>" } // for SNAPSHOT builds
}

apply plugin: 'kotlin-kapt'

def arrow_version = "0.11.0"

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib"
    implementation "io.arrow-kt:arrow-optics:$arrow_version"
    implementation "io.arrow-kt:arrow-syntax:$arrow_version"
    kapt    "io.arrow-kt:arrow-meta:$arrow_version"
}

Hey! I'm working on a cross platform application using MVI as the underlying architecture. I stumbled across an article about Arrow and using functional programming to implement simple dependency injection and I find it fascinating. I've only really done OOP so I find it somewhat confusing to see how I might incorporate Arrow; do you have any recommendations on where to start? ... Or should I just look into going back and getting a Phd in CS? 😄

Just curious, what would people think of using

%=

to avoid repeating the variable name, when using a lens to modify something? Current we have something like:

var longVariableName = Foo(Bar(Baz(5)))
longVariableName = Foo.bar.baz.int.modify(longVariableName) { 20 }

Instead, it would be possible to do:

longVariableName %= <http://Foo.bar.baz.int|Foo.bar.baz.int> { 20 }

Obviously any augmented operator works, I just chose modulus, because modulus -> mod -> modify 🙂

what is the

handleErrorWith

equivalent of with

arrow-fx-coroutines

?

ye

I am upgrading some projects to use 0.11.0, most things are fine except for one project where I use optics. The data class annotated with @optics seems to fail my build due to duplicate JVM names. (The project actually works fine if I copy the generated optics into the project and remove the annotations.) I haven’t changed anything except for versions in the pom file, so I am not sure why this is happening. Any ideas how to resolve this?

I created a (very) small library to make my life easier (and possible yours too 😉). I found that I was doing the same thing over and over again, which indicates that there is a better way to do it. In this case, I encountered it during HTTP endpoint implementations. In an HTTP endpoint, based on the request, you probably want to execute some meaningful logic. This means, using

arrow-fx-coroutines

, that it will be a suspended function. Personally I really like to work with `Either`s, so most often I end up with a signature like

suspend fun myMeaningfulLogic(): Either<DomainError, MeaningfulResult>

. When using such functions, you need to fold the returned

Either

so that you can create a response that is useful in an HTTP endpoint. And most often, just to be safe, because everything on the JVM can throw `Exception`s, you want to wrap your meaningful logic in an

Either.catch

. Which means more folding to come to a usable value. To simplify the

Either.catch

with multiple `Either.fold`s, I created a generic function that can handle any suspended function that returns an

Either

and return a desired type of value:

get("/some/http/endpoint") { // This is an example using Ktor.  
    handle(
        logic = { myMeaningfulLogic() },
        ifSuccess = { a -> handleSuccess(call, a) },
        ifDomainError = { e -> handleDomainError(call, ::log, e) },
        ifSystemFailure = { throwable -> handleSystemFailure(call, ::log, throwable) },
        ifUnrecoverableState = ::log
    )
}

This generic handler is not limited to endpoint implementations. It can handle any message or event in any framework (there is also a handleBlocking variant) and possibly there are more use cases to use it. Feel free to check it out, see: https://github.com/sparetimedevs/pofpaf. Use it if you like it. Any feedback is welcome.

Can someone please explain the difference between • arrow-fx-coroutines • arrow-fx-coroutines-kotlinx-coroutines to me?

I think I'm missing something somewhere, please tell me if I'm asking too many questions... My current understanding is that the concept of typeclasses is, essentially: • A way to make an object you don't control implement any interface you want • The next step in polymorphism (via Monad, etc, that allow to group Promise, Collections, Map etc together, which allows even more polymorphism than regular Collections can) • The idea behind it is to represent ‘behaviors', and it solves for example Java's duality of Comparable/Comparator (a Comparator essentially being an external implementation of the Comparable interface). Having this be at the language's level allows for less code duplication, and more generalization, as the same pattern of “a

sort

function that sorts the objects based on their own implementation, and a second

sort

function that sorts based on an external comparator” can be applied to many other interfaces, such as Eq, Hash, Print. If that's the concept, if I wanted to try to implement this in Kotlin, I would go with something like:

infix inline fun <reified O, reified T>.withTypeclass(typeclass: T) =
  object : O by this, T by typeclass

I believe that's not legal Kotlin syntax, but I also think it wouldn't be too hard to add this via a compiler plugin (since it's just generating a new object with compile-time known types, I don't expect it to be that hard). The idea came from the recommendation on the documentation: https://arrow-kt.io/docs/patterns/dependency_injection/#composing-dependencies

This would allow to write code like
val a = Car() withTypeclass someOrderForCars()
listOf(a).sorted() // or similar

To me, this solves all above use-cases, looks like normal Kotlin (pretty close to no code generation, no hidden complexity...). I don't see any negative sides to this approach. Of course, I'm still a student, and I have a very light background in functional programming, so I expect that there's a lot that's not apparent to me... The Arrow documentation recommends a completely different way (https://arrow-kt.io/docs/typeclasses/intro/), which if I understand correctly has the benefit of not needing a compiler plugin, but it requires to create a split between ‘typeclass' and ‘interface' that I don't see a need for. KEEP-87 seems to be yet another way of implementing this, which exclusively uses function parameters to do the combination I showed before, which would mean (if I understand correctly), that it wouldn't be able to send an ‘external implementation' to a function not specifically written with that purpose in mind. KEEP-87 also introduces a way to decide a default external implementation at compile-time, which is yet another concept. At this point I'm a bit lost on what the pro/cons of each solution are, assuming I'm not comparing pears to oranges... It seems to me like the first solution would be the easiest one to teach to Kotlin developers without FP experience, since it's so similar to what the language already does with Comparable/Comparator, so I guess that there's a good reason this is not what KEEP-87 looks like, but I don't think I have the needed experience to understand why that is... I'm very curious as to what expert's thought process looks like on these topics, sorry for this wall of text 😅

So my project is written in

IO

, and I am now converting it in

arrow-fx-coroutines

. Thing that I am not able to get my head around is how `IO`’s edge of the world conditions is taken care of if i use

arrow-fx-coroutines

When using

IO

, I was doing like this :

sealed class DomainError : Throwable() {
    object NotFound : DomainError()
    object NullInIO : DomainError()

    override fun fillInStackTrace(): Throwable = this
}

and just before sending response to client, I was doing something like :

fun IO<DomainResponse>.send(): Unit {
    return this
        .attempt()
        .flatMap { response ->
            when (response) {
                is Either.Left -> { check if it is DomainError and send appropriate response, or else  log the unknown error and send generic 500 internal server error }
                is Either.Right -> { send 200 ok response }
            }
        }
        .suspendCancellable() 
}

By doing something like this I was catching all of the exceptions which wasn’t known to me but were thrown under certain unfortunate scenarios. This kind of approach made me aware of holes in my code, and time to time I went back and fixed them to the point that there are no more surprises. I hoped that

BIO<DomainError, A>

would’ve cleaned up

DomainError

sealed class by not extending Throwable, and still covering me like

IO<Throwable, A>

, but it is reverted. How can I do this with Either ?

Either.catch

gives

Either<Throwable, A>

, and from what I’ve read here, whole point was not to use

Throwable

with

Either

.

Also trying to convert my resource release method from

IO<A>

to suspend ->

Either<Throwable, A>

, is this correct :

fun Ds.closeTxn(exitCase: ExitCase<Throwable>): IO<Unit> {
    return IO {
        when (exitCase) {
            is ExitCase.Cancelled -> this.rollback().close()
            is ExitCase.Completed -> this.commit().close()
            is ExitCase.Error -> this.rollback().close()
        }
    }.guarantee(IO { this.close() })
}

to

suspend fun Ds.closeTxn(e: arrow.fx.coroutines.ExitCase): Either<Throwable, Unit> {
    return guarantee(
        {
            Either.catch {
                when (e) {
                    is arrow.fx.coroutines.ExitCase.Completed -> this.commit().close()
                    is arrow.fx.coroutines.ExitCase.Cancelled -> this.rollback().close()
                    is arrow.fx.coroutines.ExitCase.Failure -> this.rollback().close()
                }
            }
        },
        { Either.catch { this.close() } }
    )
}

Is this correct way of doing

parMapN

?

interface SomeRepo {

    suspend fun getId(someId: Int): Either<Throwable, Int>
    suspend fun getName(someName: String): Either<Throwable, String>
}

interface AnotherClass {

    val someRepo: SomeRepo

    suspend fun <A, B> getResult(someName: String, someId: Int): Either<Throwable, Tuple2<Int, String>> {
        return parMapN(
            suspend { someRepo.getId(someId) },
            suspend { someRepo.getName(someName) }
        ) { a, b -> a.product { b } }
    }
}

the test doesn’t pass, it says

This job hasn't completed yet

when i execute

getResult

with

runBlockingTest

the other thing about the above syntax that I find different when I compare to `IO`’s

parTupleN

is why this method exists again ? In

IO

,

parMapN

was deprecated in favor of

parTupledN

because the returned type was not aligned with returned type of other apis in the library. If I use

parTupleN

from

arrow-fx-coroutines

, I was expecting that if I am giving it 2 methods with

Either

return types, it should give me

Either<Throwable, Tuple2<A, B>>

, instead it gives me Tuple2<A, B>, which then needs to be producted like I am doing above with

parMapN

.

Hopefully this is the correct place to ask about ... Arrow online courses? Any Suggestions Free and/or Paid courses 😄

Hi @raulraja we've been using arrow + reactor in our kotlin projects. Pretty excited to see arrow getting better and more accessible! Quick question around option deprecation. The services that we're having are super deep into Option. We use that primarily for avoiding null types because it doesn't play well with Reactor's translation of nulls to Mono.empty. i saw the recommendation of null types (which is off the table for us) or typealiasing either to a maybe type which may work but wouldn't that mean we have to retrofit many of the extensions on options. Is there any way we can undo the deprecation of option in some way or maybe even reintroducing it as a Maybe type in Arrow itself which is isomorphic to either? There are potentially a lot of pushback internally with the typealiasing approach. I'm more than happy to contribute to the library if need be, Arrow's option is an important piece for us.

Hi, I'm pretty new with arrow and trying to migrate my code to the new arrow.fx.coroutines. I struggled with my tests and have few questions : 1. what is it the right way to test suspend fun ? I do

assertThat(Environment().unsafeRunSync { mySuspendFunToTest(arg1,arg2) })...

2. how to delay the response of a stub method (a database query) ? I've tried

kotlinx.coroutines.DelayKt#delay

but it seems a bit strange to use kotlinx.corroutine just for that 3. how to mock a suspend fun ? I've tried

Environment().unsafeRunSync {whenever(aMock.aSuspendedFun()) doReturn aResult}

(with the help of com.nhaarman.mockitokotlin2) but it doesn't seem to work thx for your help & let me know if I miss up some documentation 🙂

I'm trying to use the shiny new fx. I tried to run my test code through

Environment().unsafeRunAsync

but neither IntelliJ nor Gradle via CLI seems to run the arrow-meta annotation processor. In

build.gradle.kts

I have:

plugins {
    id("org.jetbrains.kotlin.jvm") version "1.4.10"
    kotlin("kapt") version "1.4.10"
}

dependencies {
    implementation(platform("io.arrow-kt:arrow-stack:0.11.0"))
    implementation("io.arrow-kt:arrow-fx")
    implementation("io.arrow-kt:arrow-mtl") // from the 0.10 version
    implementation("io.arrow-kt:arrow-fx-mtl") // from the 0.10 version
    implementation("io.arrow-kt:arrow-syntax")
    kapt("io.arrow-kt:arrow-meta:0.11.0")
}

Is there anything I'm missing from the build configuration? Am I using

Environment

correctly?

How is Arrow Fx supposed to be used now? Is IO deprecated (we should use suspend instead?) I was trying to use fx as I would with for comprehension in Scala using either.eager<L,R> with suspend functions that Either.fx (from website doc) deprecation suggests. But then it seem to require the same parameters to Either for each line... Can't it be used as for comprehension?

Is there a reason compose, andThen etc don't support composing suspend functions?

I'm curious, are people in this slack interested/involved at all with kotlinx.immutable?

Hi all, I have a general question about structuring my app/State when trying to be more functional. At its core, I have a data class that represents state and I'm using a redux like setup. So when a request comes in, I follow this pattern:

data class State(val foo: Int = 1)
typealias NextState = State

// ...
val action = Action.Ping()
val next: NextState = state
  .dispatch(action)
  .save()

// Now maybe i'll grab a value off of next to send back to the user if that makes sense in the current context
//...

So this approach works fine, but I'm finding an increasing number of use cases where I want to return NextState and a Result. And I'd appreciate any feedback on what others think is a good way to handle this or a call out if my approach is bonkers ... still new to FP 🙂 I'm considering two approaches to achieve the above: •

fun <T> dispatch(action: Action): Either<Failure, Tuple2<NextState, T>>

•

fun dispatch(action: Action): Either<Failure, NextState>

In this approach I modify State to have non-serialised var that holds the return value:

data class State(val foo: Int = 1, var result: Option<Any> = None) { fun <T> getResult(): Option<T> }

Is there a better way of doing this, is there a preferred approach, is this sound? Any thoughts welcome.

I'm migrating my pet project from an MTL-based implementation with Arrow 0.10 to new Arrow 0.11 fx. I had a function that was combining results of two computations:

fun <F> Applicative<F>.combine(
    fn1: () -> Kind<F, Any>,
    fn2: () -> Kind<F, Any>
): Kind<F, Any> =
    fn1().map2(fn2) { (a, b) ->
        // do sth with a and b
    }

With Arrow 0.11 I'm trying to pass effectful computations as suspend functions. I'm able to combine them using the

either

companion:

suspend fun combine(
    fn1: suspend () -> Either<Throwable, Any>,
    fn2: suspend () -> Either<Throwable, Any>
): Either<F, Any> =
    either {
        val a = !fn1()
        val b = !fn2()
        // do sth with a and b
    }

If I want to execute the effects concurrently with

parMapN

, I'm not able to unwrap

Either

values and work with them:

parMapN(fn1, fn2) { a, b ->
        // Compile error: Suspension functions can be called only within coroutine body
        either {
            // same code as in the sequential example
        }
    }

Is there a way to combine

parMapN

with Either comprehensions?

Hi guys, is there jackson module for arrow ? If so, where can I find it? I find this repo but I the maven jar to download it https://github.com/arrow-kt/arrow-integrations

Is there any documentation by arrow team about when decisions are made for new versions like removing Option and going with kotlin nullability design and also why evrything is moving to suspended functions (mixing execution with programing sementics)

Hey guys, I'm trying to migrate some functionality from

IO

to the new

suspend

way We're calling a third-party method which returns a

CompletableFuture<Void>

and before we handled it in the following way

async {
    run {
        doSomethingAsync() //this returns the CompletableFuture<Void>
    }
}

How do I correctly go from that completableFuture to a suspend function which returns an

Either<MyError, Unit>

Hi chaps, could someone explain the deal with the

BIO

? I have seen a commit by @simon.vergauwen merged into arrow-fx and then I’ve seen it reverted. Is there a rational somewhere on GitHub maybe that I could go through? Or maybe someone would not mind explaining real quick what happened there? 🙂