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

[Daniel Fischer]

On Thursday 08 September 2011, 02:07:39, Cale Gibbard wrote:
> 
> 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,

I find that not so strange, another obvious reimplementation is the one you 
get if you compile Data.List with -DUSE_REPORT_PRELUDE,

nubBy eq []             =  []
nubBy eq (x:xs)         =  x : nubBy eq (filter (\ y -> not (eq x y)) xs)

If the relation defined by the predicate argument is not transitive, you 
get a different result than with your definition above.

Of course, the report could make a choice and say that behaviour is 
authoritative, but while the expected behaviour is clear for an equivalence 
relation (if you don't distinguish different bottoms), it's not so obvious 
otherwise.

> but the behaviour given by the Report implementation (the
> opposite of the current behaviour in GHC) is useful and desirable
> nonetheless.

Yes, although I don't think nubBy is a perfect name for that function - 
and, it's also only useful for transitive relations, as far as I can see.

> 
> 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

Nobody made a formal proposal, so it withered and died.

> came up again for me, and I decided that I was sufficiently irritated
> by it to post again.

Sufficiently irritated to make a formal proposal?
If nobody does that, it probably won't change (and I'm not interested 
enough in the matter to make one, but would support).

> 
> 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.

Supposing that the last assessment is not wildly incorrect, +1.