Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith

[apfelmus]

Alexander Dunlap wrote:
> apfelmus wrote:
>> Alexander Dunlap wrote:
>>> This seems like a good idea but it's kind of strange to have three
>>> different exposed versions of nub. Would it be possible to hide them,
>>> hide the StopList typeclass and use {-# RULES #-} pragmas to use the
>>> faster versions when possible?
>>
>> I don't think that using RULES pragmas is a good solution to the problem.
> 
> Why not? I thought that was the major purpose of RULES - to implement
> transformations that don't affect semantics. It seems silly to clutter
> up classes with extra functions just for efficiency or to have to
> change programs every time the types change. The fact that RULES don't
> work in GHCi is admittedly a downside; is there any plan to change
> that?

Why not type classes? :) Their major purpose is to overload a value at
different types, like

  nub :: Eq a => [a] -> [a]
  nub :: Ord a => [a] -> [a]
  nub :: [Int] -> [Int]

and that's exactly what we're trying to do. Adding  nub  with a default
definition is a two-line change to the definition of the  Eq  class and
it's completely backwards compatible, no existing program needs to be
changed.

But as said, Haskell98 is currently unable to specialize  nub  for a
general  Ord  context, we would need some extension about superclasses
for that. But this extension is desirable for Functor, Monad and
Applicative anyway.


The argument that the semantics of the different  nubs  are all the same
does have merits, but we're already putting functions into the class for
efficiency reasons, like

  (/=) and (==)
  (>),(>=) and  compare
  (/) and  recip
  tan  and  sin,cos
  (>>)  and  (>>=)
  etc.


Regards,
apfelmus