I believe we made them execute in order in the latest revision. In any case I wouldn’t trust `mapN` ...

# arrow

[pakoito]

I believe we made them execute in order in the latest revision. In any case I wouldn’t trust mapN to execute in order. If order matters, then use flatMap

[Gopal S Akshintala]

Thanks @pakoito, hey for contributing to Arrow lib is there any setup doc? I referred this, but felt it’s not comprehensive: https://github.com/arrow-kt/arrow/blob/master/docs/move-to-multi-repo/README.md

[pakoito]

it used to be that you could go there in one click

[pakoito]

right now just find the dock, modify it, and run ./gradlew runAnk for the whole repo

[pakoito]

it should build them

[pakoito]

cc @Rachel

[Gopal S Akshintala]

I will post in the contributors channel as well, thanks

[Jannis]

Yes this is a fixed bug. Next version will have traverse operate from left to right. The end result order depends on two things: Order of traverse, which will always be left to right from now on and the order of the applicative instance used. Which is also always left to right in 0.15.

[Gopal S Akshintala]

Thanks @Jannis, any tentative date for the release of 0.15?

[raulraja]

@Gopal S Akshintala we are working in parallel in the release of 0.10.5 with fixes and new deprecation, 0.11 which is a breaking change with Bifuctor IO and the 1.x version that piggy backs on the lang versioning with meta

[raulraja]

They’ll be coming out as available given some people had to switch some priorities due to the current world crisis going around.

[raulraja]

@paco is in charge of releasing and he may have more info regarding 0.10.5. In whatever case there is a snapshot for both 0.10.5 and 0.11

[raulraja]

if you want to try them out before available

[Gopal S Akshintala]

Thanks @raulraja, appreciate all the hard work put-in by the Arrow team, you guys are inspiring… 👏🏼… @Jannis @pakoito I have taken the 0.11.0-SNAPSHOT and the behavior of mapN remains the same as before. May I know which version has the fix available (I was previously on 0.10.5-SNAPSHOT). Thanks

[Jannis]

There are more ordering issues in product from Apply. https://github.com/arrow-kt/arrow-core/blob/master/arrow-core-data/src/main/kotlin/arrow/typeclasses/Apply.kt#L300
As you can see it first applies the other argument to this. Since tupledN and mapN use that it messes up order. When I checked order last time I must have missed them... Will do a quick pr later today

[Gopal S Akshintala]

Thanks @Jannis, that shall be a huge help, I am making use of them in a POC

[Gopal S Akshintala]

@Jannis /@pakoito Also if mapN is fixed to act from left to right, will it also take care of Short-circuting/fail-fast (means if u found a left, rest of them should not be evaluated). Currently, mapN evaluates all the expressions, like below

@Test
    fun `Left * Right`() {
        val product = Either.applicative<String>().run {
            mapN(
                    "left".left(),
                    getRight()
            ) {}
        }.fix()
        product.fold({ assertEquals("left", it) }, {})
    }

    private fun getRight(): Either<String, String> {
        println("This should not be printed") // vvv But printed
        return "right".right()
    }

[Gopal S Akshintala]

Same behavior with ApplicativeError as well

@Test
    fun `Left * Right`() {
        val product = Either.applicativeError<String>().run {
            mapN(
                    raiseAnError(),
                    getRight()
            ) {}
        }.fix()
        product.fold({ assertEquals("error", it) }, {})
    }

    private fun EitherApplicativeError<String>.raiseAnError(): Either<String, String> {
        println("raising an error")
        return this.raiseError("error")
    } 
    
    private fun getRight(): Either<String, String> {
        println("This should not be printed")
        return "right".right()
    }

[pakoito]

getRight() is eager, you’re executing it immediately

[pakoito]

and you’re passing the result to mapN

[pakoito]

if you want something that’s purely lazy, wrap it into Function0, Eval or IO

[Gopal S Akshintala]

Ya bad example from my side, but with lazy construts how can I have lazy using mapN? It always asks for result isn’t

[pakoito]

you have to use a lazy datatype like the ones I mentioned above

[Gopal S Akshintala]

Sorry, but I am still confused, probably let me show you the code where I am struck: https://github.com/overfullstack/ad-hoc-poly/blob/1a6c716e5f2aad6b5ba08b90e2ff7b29d9d8b115/validation-fx/src/main/kotlin/com/validation/rules/UserRules.kt#L33

In here I am using ApplicativeError looking for a failfast/shortcircuit, where I don’t want other methods to be called, if one of the method does raiseError

[Gopal S Akshintala]

This is similar to the Either vs Validation example I found on arrow docs

[Gopal S Akshintala]

Just FYI, I am using a combination to two effects ApplicativeError and Async in this code @pakoito

[pakoito]

use mapN(later { }, later { }) : https://t.ly/kv8BJ

[pakoito]

your types may end up differently, such as Kind<F, Kind<G, A>> so you’ll need to flatMap that outer Kind on the caller

[pakoito]

or somewhere else

[Gopal S Akshintala]

Yes, I m doing it here: https://github.com/overfullstack/ad-hoc-poly/blob/1a6c716e5f2aad6b5ba08b90e2ff7b29d9d8b115/kofu-reactive-validation/src/main/kotlin/com/sample/HandlersX.kt#L21

[Gopal S Akshintala]

and here: https://github.com/overfullstack/ad-hoc-poly/blob/1a6c716e5f2aad6b5ba08b90e2ff7b29d9d8b115/kofu-mvc-validation/src/main/kotlin/com/sample/HandlersX.kt#L23

[Gopal S Akshintala]

@pakoito, I tried this, but I still can’t achieve a short-circuit, am I doing something wrong?

@Test
    fun `IO ApplicativeError`() {
        val product: Either<String, Unit> = IO.async<Nothing>().run {
            Either.applicativeError<String>().run {
                mapN(
                        later { raiseSomeError() },
                        later { justString() }
                ) {}
            }
        }.fix().unsafeRunSyncEither()
        product.fold({ assertEquals("error", it) }, {})
    }

    private fun <S> ApplicativeError<S, String>.raiseSomeError(): Kind<S, String> {
        println("raising an error")
        return raiseError("error")
    }

    private fun <S> ApplicativeError<S, String>.justString(): Kind<S, String> {
        println("This should not be printed")
        return just("just")
    }

[pakoito]

yes

[pakoito]

raiseSomeError returns a Kind

[pakoito]

that you don’t do anything about

[pakoito]

in the {} of the mapN

[pakoito]

check it

[pakoito]

you’ll see it returns 2 kinds

[Gopal S Akshintala]

ya it returns two kinds, and mapN needs both their result to do product

[Gopal S Akshintala]

so both fns are executed

[pakoito]

yes and the shortcircuit is for an Either, not for a Kind<F

[pakoito]

the Kind is never executed so it won’t short on that raiseError

[pakoito]

val product: Either<String, Unit> =
            IO.applicativeError().mapN(
              IO.defer { raiseSomeError() },
              IO.defer { justString() }
            ) {}
        }.unsafeRunSyncEither()

[Gopal S Akshintala]

Thanks @pakoito, now I m struggling to write the other two fns. Sorry to bother, you may respond at ur leisure. Thanks.

[Gopal S Akshintala]

@Test
    fun `IO ApplicativeError 2`() {
        val product =
                IO.applicativeError<Nothing>().mapN(
                        IO.defer { raiseSomeError() },
                        IO.defer { justString() }
                ) {}.fix().unsafeRunSyncEither()
        
        product.fold({ assertEquals("error", it) }, {})
    }

    private fun <S> ApplicativeError<S, Throwable>.raiseSomeError(): Kind2<S, Throwable, Unit> {
        println("raising an error")
        return raiseError(RuntimeException("error"))
    }

    private fun <S> ApplicativeError<S, String>.justString(): Kind<S, String> {
        println("This should not be printed")
        return just("just")
    }

[pakoito]

don’t just copypaste my code

[pakoito]

I made a mistake and removed the async() part that allows calling into the other two 😄

[Gopal S Akshintala]

Do I need asynchronous here?

[pakoito]

async() is the typeclass, with ApplicativeError should be enough

[pakoito]

also, IO is not a Kind2

[pakoito]

so it may not work at all

[Gopal S Akshintala]

I m using BIO

[pakoito]

oh right

[pakoito]

then yes 😄

[pakoito]

ApplicativeError<S, Throwable> the error is fixed to Throwable too, so do applicativeError<Throwable>()

[Gopal S Akshintala]

Ya that was a desperate attempt, ideally I would prefer a string

[Gopal S Akshintala]

Over throwable

[pakoito]

ApplicativeError<S, String> , applicativeError<String>()

[Gopal S Akshintala]

Thanks, will try it out tomorrow and get back