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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
