At this moment all approved languages except Haskell used the same definition of the task, so I just adapted Haskell version to conform to the rest. Now all languages follow the same specification. Or, at least, I was able to complete all languages with the same solution :)

If still something is wrong, let me know.

Description was recently changed. Description and tests in all languages need to be reviewed for consistency now, and possibly fixed.

can confirm:

Falsifiable (after 50 tests):
"sprooxafshlxkru"
3 expected "..." but got "spr..."

@Johan - I'm getting a similar discrepancy in Haskell (my Haskell solution produces the same answer as my Python solution, which passed the Python tests, so I'm not saying the Haskell version is wrong but it does seem that the 2 translations disagree on the expected behavior):

(In case I'm not reading the error logs correctly) -> I'm assuming the syntax: "expected X but got Y" means correct answer is X and I'm returning Y? If so here are some copy-pasted errors:

Falsifiable (after 10 tests):
  "ehqi"
  2 expected "..." but got "eh..."
  
(Pressing re-attempt twice to get 2 more examples):

Falsifiable (after 23 tests):
  "kihakpbdafusfktexfswa"
  3 expected "..." but got "kih..."
  
Falsifiable (after 10 tests):
  "hjvtjkdo"
  3 expected "..." but got "hjv..."

In all 3 examples above, the Python version expects the 2nd of the 2 results also (I must admit I've reread the description a few times and it's still unclear to me what the expected behavior is meant to be)

With current tests, this can't happen.

Leaving to haskell author

duplicate issue, closing

I sacrificed my honor points to understand this problem - Here is what I found:

The only difference between an accepted solution and my code was the order of Type 'Two' roots; ( -b +sqrt) ( -b -sqrt ) .
When I flipped those to ( -b -sqrt) ( -b + sqrt ) I immediately got the green light.

I have stumbled upon this bug too. An alias of 'f' did not compile. When I changed it to 'p' I had no problems with aliases.

EDIT: After looking at solutions I am sure the problem is something else. Everyone uses 'f' without issues. I have already forgotten what code had the bug.

It's not the most elegant fix, but it's a fix. Closing.

We'll deal with Control.Arrow.(|||) when someone asks for it. :/

Thanks so much! Please resolve this issue once you've fixed it.

Commenting on the original translation suggestion would have worked - the OP gets a notification for that. I did not get one for this, but have been notified through Discord.

The current test is loc `shouldNotSatisfy` isInfixOf "|" - essentially '|' `notElem` lineOfCode.

I'll gladly take suggestion on how to fix the test elegantly, concisely and without false positives, because relying on whitespace around it is not foolproof, and searching for "|" but not "||" is not immediately obvious to me.

I don't speak Haskell :( Is there a way to notify JohanWiltink who posted the Haskell Translation?

What a lovely timing on your clarification. Thank you very much for it.