views:

986

answers:

5

What are the similarities and the differences between Haskell's TypeClasses and Go's Interfaces? What are the relative merits / demerits of the two approaches?

+12  A: 

Looks like only in superficial ways are Go interfaces like single parameter type classes (constructor classes) in Haskell.

  • Methods are associated with an interface type
  • Objects (particular types) may have implementations of that interface

It is unclear to me whether Go in any way supports bounded polymorphism via interfaces, which is the primary purpose of type classes. That is, in Haskell, the interface methods may be used at different types,

class I a where
    put :: a -> IO ()
    get :: IO a

instance I Int where
    ...

instance I Double where
    ....

So my question is whether Go supports type polymorphism. If not, they're not really like type classes at all. And they're not really comparable.

Haskell's type classes allow powerful reuse of code via "generics" -- higher kinded polymorphism -- a good reference for cross-language support for such forms of generic program is this paper.

Ad hoc, or bounded polymorphism, via type classes, is well described here. This is the primary purpose of type classes in Haskell, and one not addressed via Go interfaces, meaning they're not really very similar at all. Interfaces are strictly less powerful - a kind of zeroth-order type class.

Don Stewart
Indeed, the only relation between the two seems to be that in both cases the "methods" live independent of the "classes". That's about it.
Jörg W Mittag
+5  A: 
  1. In haskell typeclass instantiation is explicit (i.e. you have to say instance Foo Bar for Bar to be an instance of Foo), while in go implementing an interface is implicit (i.e. when you define a class that defines the right methods, it automatically implements the according interface without having to say something like implement InterfaceName).
  2. An interface can only describe methods where the instance of the interface is the receiver. In a typeclass the instantiating type can appear at any argument position or the return type of a function (i.e. you can say, if Foo is an instance of type Bar there must be a function named baz, which takes an Int and returns a Foo - you can't say that with interfaces).
sepp2k
The lack of polymorphism heavily restricts the degree to which Go intefaces are related to type classes. I would say that without polymorphism in the instance methods, they're not really related, other than superficially.
Don Stewart
+4  A: 

Very superficial similarities, Go's interfaces are more like structural sub-typing in OCaml.

snk_kid
+3  A: 

I will add to Don Stewart's excellent answer that one of the surprising consquences of Haskell's type classes is that you can use logic programming at compile time to generate arbitrarily many instances of a class. (Haskell's type-class system includes what is effectively a cut-free subset of Prolog, very similar to Datalog.) This system is exploited to great effect in the QuickCheck library. Or for a very simple example, you can see how to define a version of Boolean complement (not) that works on predicates of arbitrary arity. I suspect this ability was an unintended consequence of the type-class system, but it has proven incredibly powerful.

Go has nothing like it.

Norman Ramsey
+1  A: 

C++ Concepts (that didn't make it into C++0x) are like Haskell type classes. There was also "axioms" which aren't present in Haskell at all. They let you formalize things like the monad laws.

http://en.wikipedia.org/wiki/Concepts_(C++)

solrize