Hacker News new | ask | show | jobs
by ZenoArrow 3627 days ago
I'm not sure I understand all of what you've said, as I'm not familiar with Haskell, but there are at least some Haskell programmers have recognised the similarities between type classes and interfaces. Do you disagree with any of the following?

https://wiki.haskell.org/OOP_vs_type_classes#Type_classes_ar...

"Type classes are like interfaces/abstract classes, not classes itself

There is no inheritance and data fields (so type classes are more like interfaces than classes)....

For those more familiar with Java/C# rather than C++, type classes resemble interfaces more than the classes. In fact, the generics in those languages capture the notion of parametric polymorphism (but Haskell is a language that takes parametric polymorphism quite seriously, so you can expect a fair amount of type gymnastics when dealing with Haskell), so more precisely, type classes are like generic interfaces.

Why interface, and not class? Mostly because type classes do not implement the methods themselves, they just guarantee that the actual types that instantiate the type class will implement specific methods. So the types are like classes in Java/C#.

One added twist: type classes can decide to provide default implementation of some methods (using other methods). You would say, then they are sort of like abstract classes. Right. But at the same time, you cannot extend (inherit) multiple abstract classes, can you?

So a type class is sort of like a contract: "any type that instantiates this type class will have the following functions defined on them..." but with the added advantage that you have type parameters built-in, so:

  class Eq a where
    (==) :: a -> a -> Bool
    (/=) :: a -> a -> Bool
    -- let's just implement one function in terms of the other
    x /= y = not (x == y)
is, in a Java-like language:

  interface Eq<A> {

    boolean equal(A that);
    boolean notEqual(A that) { 
       // default, can be overriden
       return !equal(that); 
    } 
  }
And the "instance TypeClass ParticularInstance where ..." definition means "ParticularInstance implements TypeClass { ... }", now, multiple parameter type classes, of course, cannot be interpreted this way."