[lkitching]

Type classes are quite different from interfaces. How would you encode the Eq typeclass in F#? .Net has the IEqualityComparer<T> interface but you need to manually pass that around (unlike Eq instances) and you also lose the global uniqueness property.

[ZenoArrow]

You don't have to rely on the built in interfaces provided by .NET, you can create your own. Just like in Haskell in F# you can use pattern matching against types to define which of the equality operators to use.

Also, I'm not sure what you mean by "manually pass that around". When you define a class in Haskell that inherits from a typeclass you reference that typeclass in the header of the new class. You follow the same approach in F# with interfaces.

[lkitching]

By 'pass around', I mean pass around instances, not definitions. You could define your own Eq interface in F#

  type IEq<'a> =
    abstract member eq: 'a -> 'a -> bool

but you then need to explicitly pass instances of this interface around into every method that requires it e.g.

  let allEq (s: 'a seq) (eq: IEq<'a>) = ...

whereas the haskell version would receive the Eq instance for the input type implicitly.

Typeclass instances are globally unique for each type, which cannot be enforced with the interface solution. If you have an ordered map type, you can be sure the Ord instance used for insertion is the same that is used for retrieval. With the interface approach, clients cannot know which instance to use since there could be multiple implementations. The Haskell approach has its own problems, such as the proliferation of newtype wrappers to manage the dispatch mechanism.

Interfaces also hide the representation of one of their arguments (the receiver) whereas typeclasses are just a dictionary of functions.

[ZenoArrow]

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."