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, nubBool (True:True:False:undefined) 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 regards, Bertram