Status of nubOrd (Proposal #2629)
bertram.felgenhauer at googlemail.com
Wed Oct 8 08:06:36 EDT 2008
Bart Massey wrote:
> 1) Stick nubOrd' from my previous message into Data.List and
> call it a day.
I don't like it, for the simple reason that its exact strictness
properties are hard to explain. Low performance hurts, too.
> 2) Stick (non-StopList) nubWith in Data.List. Stick nubOrd
> in Data.Set, implemented using nubWith.
> Advantages: Provides a highly efficient, fully lazy
> nubOrd. Provides nubWith. Reasonable implementation.
That's nubWith :: (a -> b -> Maybe b) -> b -> [a] -> [a], right?
I have no strong opinion about this proposal either way.
> Disadvantages: Sticking nubOrd in Data.Set is weird.
That doesn't worry me much. We can always add a link to the
documentation of 'nub'.
All in all I must say that the design space for nub functions is
surprisingly big. One aspect that hasn't been mentioned yet is
special handling for finite types. For example,
could well return [True,False], because all possible values have
been exhausted at that point.
I'm not suggesting to add more functions for this - nubBool is
easily expressed as
nubBool = take 2 . nub
More information about the Libraries