( not all of these are done in this fork; I was mostly playing with the random generator )

• description examples should be example tests ( you can have more than that )
• white kata should show inputs on failure
• reference solution should be factored out
• reference solution should be as fast as possible ( I like the void thing, but showcase it in the example solution )
• random generator should be as fast as possible ( I haven't actually profiled it, but this looks faster )

The reference solution is actually unnecessary. I'll be editing that in.

Also, I saw no reason to punish users with symbols and scribbles; using letters only looks much more friendly. The JS original does the same, but shouts at solvers; using lowercase only looks, again, much more friendly.

You can modify the input.

No you can't. Even if you could, it should be forbidden; modifying inputs is bad bad bad.

Note that b can be greater than a.

This doesn't make much sense. It would be much more helpful to specify that a can be greater than b.

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.

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.

That's an issue. Reraising as such.

Description should not specify sorting to determine the minimum. Don't encourage bad coding.

Specifying the transformation on the first value before telling solvers to return said first value is better description authoring.

approved

( Haskell )

random tests do not guarantee list length >= 3. update.

approved by someone

Object.keys doesn't work on an iterable object ( well, it does, but it doesn't do what you want it to do ). You have to iterate it. Follow the link in the description and read up on the protocol.

This question was already answered here.

Not a kata issue. Closing.

I wish that too. It was originally not even supposed to be a puzzle, but people kept perceiving it as such.

Can we let it be now? I'm not changing it anyway. It is what it is, and opinions are divided. Feel free to vote your conscience.