Status of nubOrd (Proposal #2629)

[Bertram Felgenhauer]

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