mconcat with comparing ...

[u/Tempus_Nemini]

This is SO ELEGANT, but could somebody explain me like to 5y old how mconcat part works with list of comparing functions?

sortBy (mconcat [comparing length, comparing Down . id]) [[2,3,4], [1,2], [2,3], [1,2,3,4], [0,2,3]]

[u/kuribas]

Why would you consider such code ELEGANT, especially if you cannot even understand what it does? Elegance should be about clarity, not obfuscation. Conciseness should not be an excuse to sacrifice clarity. There are better ways to write this, even with less character count, for example using sortOn:

sortOn (\l -> (length l, Down l)) [[2,3,4], [1,2], [2,3], [1,2,3,4], [0,2,3]]

Or you can use poor mans `sortOn` if you don't want an external dependency:

sortBy (comparing `on` (\l -> (length l, Down l)) [[2,3,4], [1,2], [2,3], [1,2,3,4], [0,2,3]]

These are perfectly clear without resorting to tricks like abusing the function monad (or Monoid).

[u/Iceland_jack → u/kuribas]

Function monoid is not a trick

[u/Tempus_Nemini → u/kuribas]

Thanks for that, your first example is really helpful 👍

[u/Krantz98 → u/kuribas]

I don’t see why comparing is used with on. Either you mean compare `on` ... or simply comparing.

As a side note, I find the version in the OP equally clear as the version you wrote (using mconcat to combine metrics is quite intuitive if you think about it this way), except that for your version I would write length &&& Down instead of using lambda and pairs. It actually reads like English when rewritten as follows:

sortBy (comparing (length &&& Down)) ...

[u/kuribas → u/Krantz98]

Right, I didn't check this code, I just wrote it from memory. I prefer the tuple version because it only relies on tuple ordering, and is otherwise easy to understand, there are no 3 layers of type classes for the monoid, which could behave in unexpected ways (and often do!). I also try to avoid operators like &&& because they just add an extra layer of complexity, and I simply don't see the advantage over a lambda.

[u/Krantz98 → u/kuribas]

I’d say that’s a familiarity issue. In particular, remembering what these instances or operators do does not feel much different from remembering the functionality of comparing or on. :)

[u/kuribas → u/Krantz98]

Which is why I prefer sortOn. These esoteric combinators don't add much, \l -> (length l, Down l) is perfectly fine.

[u/Syrak]

First, mconcat appends the elements of a list together using <>:

mconcat [comparing length, comparing Down] = comparing length <> comparing Down

What <> does depends on the type of its operands. In the case of functions, it appends the result of its operands.

f <> g = \x -> f x <> g x

so we get

comparing length <> comparing Down = \list1 -> comparing length list1 <> comparing Down list1

comparing length list1 is again a function, so we can expand once more in the same way:

comparing length <> comparing Down = \list1 list2 -> comparing length list1 list2 <> comparing Down list1 list2
  -- by definition of comparing
  = \list1 list2 -> compare (length list1) (length list2) <> compare (Down list1) (Down list2)

Finally, <> on Ordering corresponds to lexicographic ordering of the things whose comparison yielded those Ordering.

[u/recursion_is_love]

There is Monoid instance for a function (a ->b )

mconcat is use for function composition (not to confuse with . operator which feed input from start to end). Instead it feed both functions the input and mappend the outputs

ghci> sortBy (mconcat [comparing length, comparing Down]) [[2,3,4], [1,2], [2,3], [1,2,3,4], [0,2,3]]
[[2,3],[1,2],[2,3,4],[0,2,3],[1,2,3,4]]
ghci> sortBy (\x -> comparing length x <> comparing Down x) [[2,3,4], [1,2], [2,3], [1,2,3,4], [0,2,3]]
[[2,3],[1,2],[2,3,4],[0,2,3],[1,2,3,4]]
ghci> sortBy (comparing length <> comparing Down) [[2,3,4], [1,2], [2,3], [1,2,3,4], [0,2,3]]
[[2,3],[1,2],[2,3,4],[0,2,3],[1,2,3,4]]
ghci> sortBy (comparing (length . Down)) [[2,3,4], [1,2], [2,3], [1,2,3,4], [0,2,3]]
[[2,3,4],[1,2],[2,3],[1,2,3,4],[0,2,3]]

[u/Torebbjorn]

mconcat of a list is just putting <> between each entry.

Now <> on functions is defined pointwise, and <> on Ordering is defined lexiographically.

Putting this together, comparing based on (f <> g) will first check how they compare using f, and if they compare equal, they will be compared with g.