Hold on, the range is always ascending

Hi! Thanks for the translation. I'd love to approve it, but I've got two requests (well, two and a half):

• Could you change the tests such they print the input board when they fail? (A good way to do this might be to add a helper function that takes a board and the expected result, runs the test, and prints the board if the test fails.)
• Could you add some random tests? Almost every kata on Codewars should have random tests. Partly as a guard against simple cheats with hard-coded return values, partly to catch errors that the fixed tests miss.
• Since this is Haskell, you might even add QuickCheck tests, which are a great at narrowing down the kinds of inputs that cause a solution to fail. But that's just a nice-to-have.

If you have any questions, let me know. I'm not a Haskell expert myself and I'd have to look up some of the details, but I've written a couple of tests, so maybe I can help.

Please see comments directly on respective translations.

Same as Haskell - can we have some unpredictability in exhaustive testing?

Could you try to shuffle the deck for exhaustive testing?

With exhaustive tests, fully random tests are not really necessary, but try to have some unpredictability in expected values when testing.

That's not the way to show the same code for javascript and c. It should read ```javascript, and c should not be in the list at all, and would then default to showing the first code block ( this is still less than ideal, because it relies on order of blocks that are present. better would be to show a language-agnostic code block ).

This problem may not be of your making, but you are in a position to solve it. Right now, neither JS nor C show a deck. :/

Updated

Updated, the output type is a record now

Using records would be clearer but adding a comment like you suggested is good enough too.

Is -- (black, white) enough, or should I change the output type to a two field record?

see open issue in translation

Ahh! You were correct! I was not removing the Black Pegs first, allowing for false White Peg values.

Thanks for pointing that out to me!

There should be a comment in the initial solution about black/white order in the tuple.

Your logic is correct but solution is not. In the second example we can remove the black pegs and see that you're matching three 1's inside guess with a single 1 inside answer which is obviously wrong:

Answer set:  [1,_,_,2,2,2,_,_,_,2,2,2,3,3,3]
Guess set:   [3,_,_,1,1,1,_,_,_,1,1,1,1,1,1]
Your answer: [W,_,_,W,W,W,_,_,_,_,_,_,_,_,_]