Please apply the comparison function given to nubBy to elements of the list in the order in which they occur in the list.

[Christian Maeder]

In case you further want to discuss this, I've re-opened
http://hackage.haskell.org/trac/ghc/ticket/2528#comment:10

So, I'm against your proposal, Cale, but suggest that you revert the 
order in your example (if you want to exploit this behavior).

Cheers Christian

Am 08.09.2011 02:07, schrieb Cale Gibbard:
> I just tried this in ghci-7.0.3:
>
> ghci>  nubBy (>=) [1,2,3,4]
> [1]
>
> Think about what this is doing: it is excluding 2 from the list
> because 2>= 1, rather than including it because 1>= 2 fails.
>
> I think an important convention when it comes to higher order
> functions on lists is that to the extent which is possible, the
> function parameters take elements from the list (or things computed
> from those) in the order in which they occur in the original list.
>
> If we reimplement it in the obvious way:
> ghci>  let nubBy f [] = []; nubBy f (x:xs) = x : filter (not . f x) (nubBy f xs)
> ghci>  nubBy (>=) [1,2,3,4]
> [1,2,3,4]
>
> I'm aware that the Report (strangely!) explicitly leaves the behaviour
> of nubBy unspecified for functions which are not equivalence
> relations, but the behaviour given by the Report implementation (the
> opposite of the current behaviour in GHC) is useful and desirable
> nonetheless.
>
> I'm sure I've written about this before. I'm not entirely sure what
> happened to the previous thread of discussion about this, but it just
> came up again for me, and I decided that I was sufficiently irritated
> by it to post again.
>
> Another thing perhaps worth pointing out is that the parameters to
> mapAccumR have always been backwards (compare it with foldr). Few
> enough people use this function that I'm fairly sure we could just
> change it without harm.
>
>   - Cale