
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.