This seems to yield an undesirable `Arb`. I added the output from `values(RandomSource.Default).take...

# kotest

[simon.vergauwen]

This seems to yield an undesirable Arb.
I added the output from values(RandomSource.Default).take(100). Am I composing Arb in an incorrect way?

Untitled

[sam]

So what's happening here is since arbs are infinite, the inner most one is never runs out of elements to move onto the next value of the outer loop.

[sam]

I guess flatmap only works if you have a finite generator, aka an Exhaustive.

[simon.vergauwen]

Hmm. I ported this from a ScalaTest snippet.

[sam]

Probably what you want is Arb.triple in kotest, although you can't have each arb depend on the previous one that way.

[sam]

I'll look at scalatest see how Bill implemented this there.

[simon.vergauwen]

No, that also doesn’t work because I need to depend on the values.

[sam]

I guess the problem is analogous to listOf(1,2,3).flatMap { generateSequence { 1 } }

[simon.vergauwen]

I wrote it as a custom Arb now, but it felt quite low level to achieve what I needed.

[sam]

Yeah this should be supported out of the box

[simon.vergauwen]

I’ll share it publicly online I’ve written a quite extensive suite already with 4.0.5

[simon.vergauwen]

https://github.com/arrow-kt/arrow-fx/pull/169/files

[sam]

how you finding the new property test stuff overall ?

[simon.vergauwen]

I’m loving the new checkAll support

[sam]

🙂

[simon.vergauwen]

I’m written a bunch of Arb which can probably use some improvement but we might be able to move to kotest if you’re interested.

[sam]

I thought having this Arb / Exhaustive thing was a brain wave of mine. Either that or unneeded complexity for no gain 😂

[sam]

PRs always welcome. If they're a bit rough and need some polish you can always just open an issue and paste in the impls and I can tidy them up.

[simon.vergauwen]

I’ve been using only Arb so far, but I could see where I could probably reduce stress on my test suites in quite some places by refactoring to Exhaustive

[sam]

I love the neatness of these tests

"cancelableF works for immediate values" {
    checkAll(Arb.result(<http://Arb.int|Arb.int>())) { res ->
      Either.catch {
        cancellableF<Int> { cb ->
          cb(res)
          CancelToken.unit
        }
      } shouldBe res.toEither()
    }
  }

[simon.vergauwen]

Yes, the test look amazing to what they looked like in Arrow Fx with IO 😅

[sam]

lol

[simon.vergauwen]

I finally managed to crack lowering IO into suspend and the result is quite nice

[simon.vergauwen]

Very idiomatic FP Kotlin

[sam]

that's great. I've been doing some scala again recently, and having to pollute my signatures with an effect type is really ugly

[sam]

having suspend in the function signatures is much more elegant

[simon.vergauwen]

Yes, that is completely gone now with the exact same semantics

[sam]

You're just hooking into the continuation apparatus then, like sequence {} does

[simon.vergauwen]

No, it also adds cancellation support and everything you’d find in an IO impl

[simon.vergauwen]

parTraverse, parMapN, raceN all those kind of operators

[sam]

oh right, wow

[simon.vergauwen]

It’s a complete rewrite of Arrow Fx in suspend

[sam]

will this will become the default impl

[simon.vergauwen]

And there is a lot more cool similar stuff in the works coming up soon 😉

[sam]

https://github.com/kotest/kotest/issues/1500

[sam]

Might not make it into 4.1.0 depending on how long it takes me to fix it. I'll get list shrinker into 4.1.0 though.

[sam]

And you've got the overridden choose going into 4.1 as well

[simon.vergauwen]

Awesome! 👍

[simon.vergauwen]

And thanks for the amazing test library! 👏

[sam]

Thanks for using it 🙂