Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt,
nubWith
apfelmus
apfelmus at quantentunnel.de
Wed Oct 1 05:34:23 EDT 2008
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
More information about the Libraries
mailing list