Of course, I was just commenting because for me, as a mathematician, it was on the first glance confusing that this actually works :D

To be fair, the type definition is Int -> Int, not (Num a) => a -> Int, so a Double would never be allowed into the function.

<*> is objectively better than =<< for this use.

Note that this definition would not work for Double, e.g. 2.25=1.5^2 would be sent to 2^2=4, because 1.5 gets rounded to 2, although 2.25 is closer to 1 than to 4.

Nice! So clean

agraboso made a good point, I think it would be good to state, that we are required to return the most minorized sequence possible. (or smth like that, as opposed to majorizing sequence https://en.wikipedia.org/wiki/Majorization)

Pick the first one. [1,2,3,6] comes before [1,2,4,5].

The problem is ill-posed: one of the sample tests (in Haskell) say
solve 12 4 shouldBe [1,2,3,6]
But [1,2,4,5] is another solution: 1+2+3+6 == 1+2+4+5 and gcd [1,2,3,6] == gcd [1,2,4,5]. How do you choose?

Also there is no mention in the description that the solution list should be ordered, yet you are requiring it.

Missed the descending order part.

If the input was [0,1,0] 
In descending order: [1,0,0]
Sum: (1 - 0) + (0 - 0) = 1 + 0 = 1

What's the issue?

Falsifiable (after 5 tests and 6 shrinks):
expected: Just 1
but got: Just 2
[0,1,0]

This was reported two years ago but it hasn't been fixed. Is there any way to do so without the translator's involvement?

https://github.com/Codewars/codewars.com/issues/1592
https://github.com/Codewars/codewars.com/issues/1683

I've solved this in Haskell, but it still shows as a non-completed kata

In the Haskell version, I defined a function named choose. It all went OK with the sample tests, but then the final try failed because there is another function named choose in scope for those tests. I fixed it by renaming mine to choose', but that is still quite annoying... Maybe a qualified import could be used to avoid this name clash.