<@U12AGS8JG> i’ve got a proposition for you. It’s ...

# kotest

[mitch]

@sam i’ve got a proposition for you. It’s about introducting continuation-passing style to the current arbitrary builder to improve its ergonomics and simplify how we might build, compose, and generate arbs. I’ve got a PR up for you to hopefully illustrate the proposed solution as well as the problem that solves.

Hope you can take a bit of a peek when you’ve got the time

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

[sam]

I'm away atm but it looks interesting when I glanced. Will review properly later.

[Gavin Ray]

Seems like a really nice idea to me! Though I've no idea what would be involved from an implementation point-of-view

[mitch]

@sam what do you reckon in general?

[sam]

Yeah we can merge it, I just want to understand it first, and I haven't had chance to look at it again

[sam]

I think its a breaking change right? Bcause you can't use suspend instead arbs anymore (in case someone was doing that)

[mitch]

thinking

[mitch]

you’re right initially i thought that wouldn’t be breaking but in terms of signature when it got compiled down it might

we changed:

// from this
fun <T> arbitrary(fn: (RandomSource) -> T): Arb<T>

// to this
fun <T> arbitrary(fn: suspend ArbitraryBuilderSyntax.(RandomSource) -> T): Arb<T>

and that’ll generate a different function

class BuildersKt {
  static Arb<T> arbitrary(Continuation, ArbitraryBuilderSyntax, RandomSource -> T) ...
}

[mitch]

i don’t like breaking changes hmmmm

[sam]

you could come up with a new name for it

[mitch]

what’s your recommendation @sam?

[sam]

fun <T> fix(fn: suspend ArbitraryBuilderSyntax.(RandomSource) -> T): Arb<T>

not sure what the name should be

[mitch]

in kotlin std lib these types of builders usually come as a lowercase of its classname. so thinking out loud

fun <T> gen(fn: suspend GenBuilderSyntax.(RandomSource) -> T): Gen<T>

or in a different package

package io.kotest.property.arbitrary.builders

fun <T> arb(fn: suspend GenBuilderSyntax.(RandomSource) -> T): Arb<T>

I just realized we can also support Exhaustive<T>.bind() if you’re cool with it.

[sam]

we had arb before and just removed it

[mitch]

yeah that’s my reluctance as well

[sam]

and gen is a bit too generic, I think its better to come up with a name that indicates this builder is a bit funky

[sam]

lol arblicative

[mitch]

lol

[sam]

what are some words that cover what we're doing, we're building, and extracting, its like a special do notation, a comprehensive of sorts

[mitch]

this solves a lot of our problem, we had like a very deeply nested data class that currently looking like callback hell because each of the fields have some sort of edge cases.

[sam]

arbcomprehension

[sam]

arbDo

[sam]

arbitraryDo doArbitrary

[mitch]

scouting arrow they name it under .computation package

[sam]

bind

[mitch]

bind isn’t bad

[sam]

our existing binds won't clash I don't think

[sam]

because they take > 1 args

[mitch]

checking

[sam]

I think you're good because bind takes arbs + a fn

[mitch]

yeah they wont. in this case though, would you recommend

Arb.bind {
   val one = arbOne.bind()
   val two = arbTwo(one).bind()
   Foo(one, two)
}

or

bind {
   val one = arbOne.bind()
   val two = arbTwo(one).bind()
   Foo(one, two)
}

I personally like the latter

[mitch]

but it’s also confusing, i’d rather see something like

arbitrary {
   val one = arbOne.bind()
   val two = arbTwo(one).bind()
   Foo(one, two)
}

[sam]

I think arrow did something similar thought, like

either {
   val a = myeither.either()
   val b = myeither2.either()
}

[mitch]

yeah they do that, they just put it under arrow.core.computations.either and arrow.core.computations.option

either {
   val a = myeither.bind()
   val b = myeither2.bind()
   b
}

the nomenclature is also the same, .bind()

[mitch]

https://github.com/arrow-kt/arrow-core/blob/master/arrow-core-data/src/main/kotlin/arrow/core/computations/either.kt

[sam]

so you don't like bind + bind

[mitch]

yeah it feels clunky, especially with kotlin stdlib and arrow have converged to doing

val flowValue: Flow<X> = flow {
  ...
}

val eitherValue: Either<L, R> = either {
  ...
}

val sequenceValue: Sequence<A> = sequence {
  ...
}

[sam]

well they have generateSequence too

[sam]

and one is suspend

[sam]

one isn't

[sam]

exactly like you're doing

[sam]

so maybe generateArbitrary

[mitch]

ah nice

[mitch]

recap say we do that:
• sequence is suspend, generateSequence is non-suspend,
• arbitrary is non-suspend, generateArbitrary is suspend
we’ve flipped the definition in stdlib. does that matter?

[sam]

I would say this kind of bind is advanced functionality, so you're only likely to use it if you know about it, and see it in the docs, so it doesn't matter hugely what it's called

[sam]

but it's not ideal that it's opposite to the std lib in this case

[sam]

you could call it arbitrary and put it in another package

[mitch]

i think i’m more inclined to do that now. i’m weighing the options

[mitch]

are you sure if we change the signature of the current arbitrary that’s a breaking change?

[sam]

its not about adding the receiver but the fact you're restricting suspension

[sam]

arbitrary { delay(100) }

[sam]

that won't work anymore because you're using suspension for your bind

[mitch]

does that ever work?

arbitrary { delay(100) }

currently arbitrary isn’t inline

[sam]

is arbitrary not marked as suspend

[sam]

aha !

[sam]

then you get a get out of jail free card, there's nothing to break

[sam]

you can change the existing one then, and add a generateArbitrary that is suspendable, mirroring the std lib ?

[mitch]

yeah that’s a new feature to be able to call suspend fun inside of the arbitrary builder.

[sam]

yeah I assumed the function was already suspendable

[sam]

well you know what they say about assumptions, it killed the cat

[mitch]

😆 i wasn’t too keen to make breaking changes either

[sam]

well sounds like we're set 🙂

[sam]

I'll review it again later as I wanted to read the comments you added

[sam]

but we'll merge it before 5 M2

[mitch]

thanks!

[sam]

I think kotest property testing must be, or close to being, the most powerful out there now.

[mitch]

haha 100%!

[mitch]

@sam i just checked that generateSequence isn’t suspend

[mitch]

and i wasn’t sure what to name it, naming is hard 😢

[sam]

not sure we need it then ?

[sam]

sorry to waste your time

[mitch]

hmm, not really a waste of time i don’t think. that suspend arb is actually quite cool

[mitch]

that’ll allow an arb to coordinate something with ext service, or gather data from local postgres or stopping / starting dynamo for instance

[sam]

right

[mitch]

Mockk name the methods coXYZ, i don't like it but it's an idea, 🤔 another idea that i got is suspendArbitrary

[mitch]

This is such an advanced feature though @sam

[mitch]

Actually I am overthinking it, you're right generateArbitrary is actually a great name. It does imply that some more effectful operation can happen

[mitch]

I'll update the PR

[mitch]

done! thanks @sam