That explains the neat

duplicate

definition ^-^ I think I got it. Not sure how comonads are useful yet, but thats a different story I guess... That also explains how

cobinding

works. Also I think I know why the test is wrong and I am pretty surprised this works for every other datatype ...

In short, the assumption the test was checking is just wrong. So this is a case of having a wrong test. Thats one for one on the pr (one broken test, one actual bug). Thanks a lot 👍

Comonads are useful modeling the guts of UIs, streams and other places https://www.47deg.com/blog/conway-swift/

Screen Shot 2019-12-18 at 8.59.08 PM.png

that’s how coflatmap works for NEL

each time it gives you a shorter version

Thanks @tomasruizlopez for that jewel arrow ❤️

That's quite impressive, that is a really elegant solution 😅 I definitly need to look out for comonadic code more and actually use it this way...

even though our gradle wrapper is at 6+

This one should be ready: https://github.com/arrow-kt/arrow/pull/1884 It changes monad, selective and applicative laws to use actual `Gen`'s rather than just

Applicative.just

for test data. This lead to a lot of failed tests, pretty much all of them were the recently added monad-applicative-consistency laws. I've fixed those in place. Now every applicative, by default evaluates the left effect first and then the right one. That is a good standart for arrow I think. The reason these were backwards in so many cases is likely because both haskell and cats define

ap

with a different argument order than arrow (they expect the

f (A -> B)

first wheres as we expect

f a

first). As applicative has no order semantics it does not matter which it is as long as it is consistent across the entire hierarchy, which is what these laws test. For readability I think it makes sense to have

IO { println(1) }.ap(IO { { _: Unit -> println(2) } })

print 1 and then 2. (Which using only applicative methods is not guaranteed). This example with only a monad constraint would have printed 2 and then 1 before ^^ This is also the cause why

traverse

with different constraints could have caused different order on the returned collections.

Thanks everyone for their suggestions and patience with this PR arrow

we have a PR for a breaking change, that’ll flip the order of the elements in Applicative

Hi arrow contributors!!

Arrow is growing more and more

and we'd like to be ready to continue growing

and we'd like to share with you a coming repository organization:

Nvm

Also I believe current implementation of

fork

for (at least) RxJava is broken. The following test case demonstrates the issue:

"Fork Fiber is cancelled when chain is disposed before emission of Fiber" {
      val dispatchers = MaybeK.dispatchers()

      val c =
        object : MaybeKConcurrent {
          override fun dispatchers(): Dispatchers<ForMaybeK> = dispatchers
        }

      val testScheduler = TestScheduler()

      with(c) {
        var emitter: MaybeEmitter<*>? = null
        val innerCtx = testScheduler.asCoroutineContext()

        val d =
          Maybe.create<Int> { emitter = it }
            .k()
            .fork(innerCtx)
            .continueOn(innerCtx)
            .flatMap(Fiber<ForMaybeK, Int>::cancel)
            .value()
            .subscribe()

        d.dispose() // Dispose the chain before the Fiber is cancelled or the Maybe is executed, commenting out this line makes test passing
        testScheduler.triggerActions() // Now process the Fiber emission and Maybe execution

        assertNotNull(emitter)
        assertEquals(true, emitter?.isDisposed)
      }
    }

Failure:

arrow.fx.MaybeKTests > Fork Fiber is cancelled when chain is disposed before emission of Fiber FAILED
    java.lang.AssertionError: expected:<true> but was:<false>
        at org.junit.Assert.fail(Assert.java:88)
        at org.junit.Assert.failNotEquals(Assert.java:834)
        at org.junit.Assert.assertEquals(Assert.java:118)
        at kotlin.test.junit.JUnitAsserter.assertEquals(JUnitSupport.kt:32)
        at kotlin.test.AssertionsKt__AssertionsKt.assertEquals(Assertions.kt:51)
        at kotlin.test.AssertionsKt.assertEquals(Unknown Source)
        at kotlin.test.AssertionsKt__AssertionsKt.assertEquals$default(Assertions.kt:50)
        at kotlin.test.AssertionsKt.assertEquals$default(Unknown Source)
        at arrow.fx.MaybeKTests$1.invokeSuspend(MaybeKTests.kt:86)
        at arrow.fx.MaybeKTests$1.invoke(MaybeKTests.kt)

Explanation:

override fun <A> Kind<ForMaybeK, A>.fork(coroutineContext: CoroutineContext): MaybeK<Fiber<ForMaybeK, A>> =
    coroutineContext.asScheduler().let { scheduler ->
      Maybe.create<Fiber<ForMaybeK, A>> { emitter ->
        if (!emitter.isDisposed) {
          val s: ReplaySubject<A> = ReplaySubject.create()

          // Here we susbcribe to the upstream, it is active from now on
          val conn: RxDisposable = value().subscribeOn(scheduler).subscribe(s::onNext, s::onError)

          /*
           * Here we emit the Fiber to the downstream, 
           * this is the only guy who can cancel the upstream.
           * But if there is an observeOn operator somewhere down the stream,
           * then there is a race condition.
           * If the downstream will be disposed before observeOn processes
           * the emission of the Fiber, then it will never reach its listener 
           * and will never be cancelled.
           */
          emitter.onSuccess(Fiber(s.firstElement().k(), MaybeK {
            conn.dispose()
          }))
        }
      }.k()
    }

Should I submit the issue or is it expected? Or maybe I'm missing something?

yes, please, do document any errors you find

and we’ll do a pass on all of them

@addamsson thanks so much for the help! @Rachel is finishing up the split for the Arrow org and our plan is to tackle

arrow-core

as first module. Additionally we are gonna do the same with the rest of the modules introducing meta and type proofs which replace kapt and the current annotation processors. It also replaces the binding reflection tricks and dependency on suspend functions for bindings. This should make us MPP. We expect the split to happen between today and Friday. When that happens and we have the

arrow-core

repo in a branch with meta as dependency we can split work and document what a module needs to do to be MPP so others can help with the rest of the modules. @Imran/Malic @simon.vergauwen and myself are initially gonna help with the effort of refactoring modules to make them dependent on Meta so we can eliminate all the arrow hacks that tie it to the JVM.

Fellow contributors, the split of the arrow org in multi repo is happening this week. @Rachel is leading this effort and she will provide instructions for lingering PRs to get relocated to the appropriate repo. We are splitting arrow in a multi repo with modules organised per library so that we can provide a better experience to contributors that is focused in the features arrow provides. Also we are enabling versioned multisite for the different libraries so each library can have it’s own space as a top level module in the Arrow Org and provide users history in the docs and independent release capabilities. CI is being rewired to account for when a lib changes breaks transitively other builds in the org that will be checked on each PR to any of the repos. All that brought to you by @Rachel 🙌

Thanks @raulraja!!

Fellow contributors, this is the expected organization with 9 new repositories:

We'll provide details about how to manage workspaces and the current PRs very soon!

an easy PR to review

Hi fellow contributors!

However, the move will take place the next week