damn

If you were writing a complete stack including NonEmptyT, the implementation could probably be made to not need an outer ListGen, right?

I've been playing with it for several hours. It's a lovely piece of work! :]

Writing a custom monolithic newtype probably often ( I think ) allows optimisations that a stack doesn't. And looking at ASCIIStringT NonEmptyList, that ASCIIStringT had better map to ASCII instead of filter to it, or it's not guaranteed to maintain the non-empty invariant. Interactions may do unexpected things ..

If I'm extending QuickCheck, I'd go whole hog, write a NonEmptyT as well, and throw in an innermost Identity. If it's worth doing at all, it's worth taking it all the way to Identity, and possibly beyond.

Go check out my other fork. I wasn't sure if I could keep everything as a newtype so DerivingVia would still work, but I found a solution.

Turns out you can keep everything as newtypes after all!

You could extend QuickCheck by taking each list wrapper and

• write an Unwrap instance
• create a "transformer" variant of the wrapper that is an instance of Unwrap and Arbitrary

Then, you can add invariants to your heart's content!

newtype Input = Input String
  deriving Arbitrary via SortedT (DistinctT (ASCIIStringT NonEmptyList)) Char

I'm not sure how useful this would be in practice if your invariant isn't some combination of the pre-defined variants, as you wouldn't really be saving much effort compared to writing a non-transformer newtype with the appropriate Arbitrary instance.

If you wanted SortedList (NonEmptyList Int), this wouldn't work; you'd still have to define your own Sorted like Distinct here.

If Sorted and NonEmpty were defined ( somewhat, not exactly ) like Distinct here, you could use SortedT (DistinctT (NonEmptyT (Identity Int)). That's where I was going with "transformer-like" newtypes ( which would then have to be datas, defeating the purpose ).

How would Sorted (Distinct (NonEmptyList Int)) look? What's here, and then newtype Sorted, instance Wraps (Distinct (NonEmptyList)) ? It doesn't look very scalable, the boilerplate explodes. It's already quite a bit more than the original forAll. That has no shrinking, but that can be added with forAllShrink and a shrink that's no larger than it is here. All the rest basically expands on nub <$> listOf1 arbitrary.

What in tarnation is happening here?

Was about to comment the same thing!

For anyone wondering why you can use bool as 1 and 0 https://github.com/python/cpython/blob/main/Doc/c-api/bool.rst#id3

Booleans in Python are implemented as a subclass of integers.

way more faster than my two for loop dumb solution

genius

It's not a bug. In that case the runner's name is Second Runner.