Please apply the comparison function given to nubBy to elements of the list in the order in which they occur in the list.
daniel.is.fischer at googlemail.com
Tue Sep 20 15:26:01 CEST 2011
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]
> I'm aware that the Report (strangely!) explicitly leaves the behaviour
> of nubBy unspecified for functions which are not equivalence
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
> but the behaviour given by the Report implementation (the
> opposite of the current behaviour in GHC) is useful and desirable
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.
More information about the Haskell-prime