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