I believe that the Haskell translation has errors in the Random Tests:
Falsifiable (after 13 tests):
expected: [52,80,96]
but got: [40,96,104]
54

[52,80,96] is NOT a Pythagorean Triple (52 * 52 + 80 * 80 = 9104 and 96 * 96 = 9216

I verified that my code produces the correct triple of [40,96,104], so it's not simply a case of tests reversing the expected and tested results.

I realized immediately after submitting my previous solution, that one of my branches was completely redundant, so I simplified it down to this strictly superior solution.

Yes, it's not pretty, but it's the implementation that I remembered from school.

Initially I implemented pred with Haskel tuples, but I resubmitted using a lambda based implementation.

I'd love to see a more elegant version that doesn't rely on Haskell types (other than functions, obviously).

I would argue that your definition of nat for Church cheats by passing the buck to maybe. Embedding the Maybe type in lambda calculus is non-trivial, and that's where the interesting code would be.

The type of the Haskell function should be either [Int] -> Int or [Int] -> Maybe Int. Null lists are happily represented as empty lists. There's almost never a good reason to distinguish between them. However, one could argue that the result for a input list with fewer than two elements should be Nothing rather than zero (hence the [Int] -> Maybe Int).

Hah, this is an excellent demonstration of why point-free style should never be a goal in and of itself. It's also an excellent demonstration of why value being iterated over should always be the right-most parameter.

This is still an issue with the Haskell test cases.

Excellent. It now works as I'd expect.

Your test program is splitting "word1..word2" into ["word1","","word2]. My program is ignoring the extra whitespace and splitting that into ["word1","word2"].

If you intend for consecutive spaces to give an empty word, then the description should explicitly mention that. The current wording ("You are given a string s made up of substring s(1), s(2), ..., s(n) separated by whitespaces") is easily interepretted to mean that substrings are separated by any number of whitespaces.

For Haskell: The "Random Tests 2" section of the submission test expects zero character words, which must be a bug in the test:

Random Tests 2
Falsifiable (after 2 tests):
expected: " OPU VGSYK b"
but got: "opu VGSYK b"
["opu","","","vgsyk","b"]

Looks good!

The Haskell version is VERY non-idiomatic.

The function should be renamed to getReversedColor.

The input validation should be handled by wrapping the result in a Maybe

So, the function would be getReversedColor :: String -> Maybe String. The function would return Nothing when given invalid input.

The Haskell version has several issues:

1. The Boilerplate code uses FillGaps for the module name, but the submission test tries to import FillTheGaps.
2. The provided test code has a syntax error on line 8. The printf is unnecessary and breaks compilation, since it isn't imported.
3. fill_gaps should be renamed fillGaps, because Haskell very strong prefers camelCase by convention. (Underscores in the middle of identifiers detracts from readability, because they look like spaces at a glance, and the space is very significant in Haskell being function application.)

My solution, which rounds to the nearest Int rather than flooring to the lower integer, passes all the tests. Either the description is wrong or a test case should be added (random cases should catch this).