Johan, I appreciate your thoroughness :p
My Haskell and Python solutions are similar algorithms, and I can see Python solutions that are effectively brute-forcing the solution space. On my machine, testing a similar Haskell algorithm with no reference solution and the current test setup (i.e. testing the runtime of these algorithms) ran for three minutes before I stopped it. For 100 tests, your solution runs in ~0.04 seconds, while mine runs in ~61.

The current Haskell test fixture is much more stringent than Python's. I'm using Test.QuickCheck to test it, while the Python tests are custom rolled and much smaller. I'm tempted to change the reference solution to yours for the time being, and then try to update the Haskell tests to be more like the Python ones. I'll resolve this issue once I rework the tests. How's that sound?

Done. I apologize for my inexperience, and I massively appreciate your help and feedback with everything!

I believe this has been fixed now. If you provide a Just answer value, the tests will validate this solution; providing a Nothing value will still run the reference solution to check that there truly is no solution.

The first iteration of the Haskell translation had 30 random tests, but for whatever reason (perhaps due to upgrading to GHC 8.8.4?), I've had to lower that. This might also be fixed by optimizing the reference solution, and I may try that later.

If a variable is not assigned a value in your answer, the tests will assume any usage (whether it be -x or x) is False. I can't speak to how the Python tests approach that, so I'm hesitant to edit the description.

Please verify it works, and resolve the issue if so.

Fixed.

This should be fixed now. I'm not sure what kinds of edge cases need to be added, and I haven't messed with Test.QuickCheck before, so I'm not entirely sure how to fix that issue.

Haskell translation submitted, please review and approve.

On second thought, this would break functionality with (>>>), so don't do it. If we change the type as suggested, this:

consume $ produce [0..10] >>> add

would turn into this:

consume $ produce [0..10] >>> (add >> return ())

Effectively, this would prevent the use of add and duplicate, because it would always require the return () tacked on.

• Done
• Done (Although this was to be consistent with the js version, but I was on the fence about that)
• Done
• Removed
• Done

Thanks for the feedback! Appreciate it.

Python translation written, please approve!

Ah sorry, here it is

Python translation created! Please approve.

Consider changing the types of add and duplicate from what it is:

duplicate :: Coroutine r v v ()
add :: Coroutine r Int Int ()

to this:

duplicate :: Coroutine r v v Void
add :: Coroutine r Int Int Void

to be more indicative of intended behavior (namely, that they never terminate).

Love this kata!
One question: Can somebody point me toward a resource that helps with the jane.can functionality in Python? I keep getting a NameError: name 'name' is not defined, even after defining it in the global namespace. Any help is appreciated!

• The function name is now in snake_case
• The function now is passed a copy of the dictionary
• The comments are removed

For your fourth bullet, the "should work for random tests" shows up if the user fails a random test. I suppose it isn't strictly necessary, but it's more descriptive than the default message.

This is my first kumite that I've actually finished, so I'm not sure how to deal with the random tests. If you have any suggestions, let me know or feel free to implement them yourself!