I just realized how useful the little on
-function can be.
Ex:
orderByLength = sortBy (compare `on` length)
But unfortunately, the inferred types can be somewhat counter-intuitive.
According to the very definition
f `on` g = \x y -> f (g x) (g y)
one could e.g. replace
(==) `on` length
with
\x y -> (length x) == (length y)
But both have different types!
The first has [a] -> [a] -> Bool
whereas the second has the correct, more generic type of [a] -> [b] -> Bool
.
This disallows obviously correct terms like (on (==) length) [1, 2, 3] ["a", "b", "c"]
(which should yield True
but now even fails type-checking).
I know this restriction comes up due to the usage of first-rank types, but how to overcome this? Can someone formulate an implementation of on
that can deal correctly with polymorphic functions (using universal quantification/rank-n types)?