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
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]
> [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.
More information about the Haskell-prime
mailing list