s/subclasses/classes/ Sorry for the confusion. Miguel Mitrofanov wrote:
I'd say we don't really need subclasses. I mean, what's the difference:
class Eq a where (==) :: a -> a -> Bool instance Eq a => Eq (Maybe a) where Nothing == Nothing = True Just x == Just y = x == y _ == _ = False sort :: Eq a => [a] -> [a]
or
data Eq a = Eq {eq :: a -> a -> Bool} eqMaybe :: Eq a -> Eq (Maybe a) eqMaybe e = Eq {eq = eqM} where eqM Nothing Nothing = True eqM (Just x) (Just y) = eq e x y eqM _ _ = False sort :: Eq a -> [a] -> [a]
Replacing classes with types, we only lose one thing: the compiler won't deduce the right instances for us. I'll trade it for the ability to abstract over them. After all, we CAN deduce the right instances by hand, it's just a finite amount of work (not very big, in my experience).
Pasqualino "Titto" Assini wrote:
Hi, just a silly question (or maybe more than one):
In Haskell we have data types (Integer,[a],...) as well as type classes (Num, Ord...).
But, if we have type classes do we still need types?
Why shouldn't the objects that we process be defined only by their 'interfaces' (assuming that a type class is a kind of interface)?
Maybe the real question is: are type classes a more primitive concept than data types?
And if so, in a language that had only type classes what would a data declaration like the following map to:
data List a = Cons a (List a) | Nil
And what about pattern matching? Would that still be possible, and what form would it take?
And finally, would having only type classes make the type system any simpler?
Thanks,
titto _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe