okok

It calls toString on the values generated to print them out after the property check completes. We can disable that if it's an issue

it’s not wrong to do that. What surprises me is that it bails on functions

The other thing we want to do is start using

Show

to generate printable strings rather than toString. I don't know if we should look up instances using SPI or if there's a better way

Could it be configurable without having to inject using instance lookups? If you don’t want to couple to Arrow, simply passing an additional parameter

(A) -> String

and from our side we can add the Show wrappings

Sorry, I don't understand what you mean

I'm a bit stupid

I’m thinking about it myself xD

Maybe if

Gen

had a function for

toString()

with a default

Oh ok I see

It could, why would you prefer that over a Show instance out of interest

if you’re using Arrow in the implementation, I’m more than happy with a Show instance!

interface Gen<A> {
  fun show(): Show<A> = Show.any()
}

that’d be enough

Yes that's one way, would work for Gens. My idea for general purpose assertions, say you are doing

person shouldBe Person("sam")

then it will call .toString on person, but if there was a Show[Person] registered via SPI then it could look it up and use it.

That strategy would also work for Gens

what about things with generics?

like

Show<A<B>>

?

it could not be specialized on the generic, right? there should be one for all implementation

yes

Hmm

so

Show<A<Int>>

!=

Show<A<User>>

it’s the typeclass problem hahaha

Well we'll know the runtime types of it all of course, so I'd know if it was a

Show<Foo<Boo>>

by introspecting the types. I don't know if that helps.

😄

If KotlinTest

Gen

module depended on

arrow-core

we can just derive anything we need in the arrow side because it would allows us to provide instances for Gen including automatic derivation for data classes, etc. https://github.com/arrow-kt/kotlintest/blob/rr-kotlin-test-arrow-revamp/kotlintest-assertions/src/main/kotlin/io/kotlintest/properties/Gen.kt#L57

But if it doesn't all we can do is rewrap it increasing allocations to end users for no reasons. It's a limitation of Kotlin but it would definetly make Gen more powerful

You can now use Gen in

fx

as a monad and create complex generators even for effectful functions

I'd want it for Gen Applicative alone

but for that it need to include the higher kinded boilerplate

yeah Applicative, Comonad