This is really nice!

Possibly this is another place where we might need to propagate the instances required of A.

Naively:

trait GenF[-R, F[_], Caps[_]] {
   def apply[R1 <: R, A: Caps](gen: Gen[R1, A]): Gen[R1, F[A]]

I'm thinking of the situations where, in order to create F[A], the A itself must satisfy some properties.

Or maybe there's a simpler way.

In general in order to perform these checks, we would require type class instances for the parametric A, such as Equal, for example. This to me suggests maybe Law1 etc should be parameterized by two things:

The higher-kinded type class (in this example, Covariant), and the set of type classes that must be satisfied by the parametric types (e.g. Equal).

Although that does raise other complications, such as where do these types come from. If the user has control of the type classes, then they also need to have control over the "poly" gens for the types.

Yes I was thinking about that as well. I think the way we solve it is with EqualF, which gives us a way to determine whether two F[A] values are equal given a way to determine whether two A values are equal. I don't think it is enough just to have a way to determine whether two A values are equal because we don't know how to compare the F[A] values. We could implement this similarly to how we did GenF.

I do think we need EqualF and friends.. then we can compare the F[A] given an Equal: A. But where will we get that Equal[A]? The function is polymorphic in A so has no structure on A. So it seems we need them both: propagating capabilities on the types down, but also polymorphic basic type classes like EqualF`.

Yes. Ideally from the perspective of the caller we would like to remain fully polymorphic in the A type. Potentially this aspect of the functionality could best be provided along with the library that defines the type classes. Then we could say "the law has to operate on abstract types A, B, and C and the only guarantee we will give you is they have this structure". And then under the hood the test framework just uses something like integers that have all this structure.

I think you are right. The downside of that is I think that means we will need the caller to provide us with a generator of A values with the required capabilities. We will then take it and hide the actual type in everything we do but we need some way to generate values with the required capabilities.

Yes, agreed. And it's unfortunate, but it kind of makes sense, if you think about constrained functors, for example, you can only map them to specify types (e.g. types that are serializable), so the user is going to have to ultimately provide the gens for values that have the required properties, but like you say, we can hide it in the actual laws.

I briefly thought about having something like G <: GenPoly. If you propagated that in sufficient places, you could put the type class instances in there. Maybe not quite as nice to use from a syntactic perspective, because the instances aren't implicit, but maybe better integrated with the GenPoly machinery.

Yes that is definitely something we could explore.

I wonder what all the tradeoffs are between F[A] and F[B], versus two F[A]. Probably n different types is fine, as long as they all satisfy the same instances required by the laws.

I think this implementation gives us the best of both worlds because at least right now all the underlying types are integers but the users and authors of laws aren't allowed to know anything about the types. So I think it makes sense to have them all be different to force the user to put the types together in the right way.

Maybe we end up with something like:

So you can do things like Covariant[Foldable, Equal, Any], which would say, my Foldable laws can operate on any A for which Equal is defined.

Or maybe there's a simpler way.