On Fri, Feb 01, 2013 at 08:25:43AM -0500, Bob Hutchison wrote:

On 2013-01-31, at 6:36 PM, Mateusz Kowalczyk wrote:

...

Greetings,

I often wonder how one would explain type classes to someone coming from an environment such as Java. Whenever I think about type classes, I seem to think of them as Java interfaces. Bah, even the bottom of [1] states

...

Haskell classes are roughly similar to a Java interface. Like an interface declaration, a Haskell class declaration defines a protocol for using an object rather than defining an object itself.

Is there more to this `roughly similar' statement? Syntax is an obvious difference but beyond that, I can't think of anything I can do with a Haskell type class that I wouldn't be able to do with similar amount of effort with a Java interface, except for the fact that the interface would look absolutely disgusting syntax wise.

Any insight appreciated.

Well I have limited insight but…

Type classes can provide default implementations, which is not possible in Java.

Type classes in a type signature describe or constrain a type and but are not themselves types. Among other things, this means in Haskell that collections must be homogeneous in their actual type, it's not sufficient to be "homogeneous in a type class". There are extensions to GHC that make this possible [1] but there are limitations and the usage has its detractors [2]. In Java you can have collections of objects that conform to a given interface even if they are of different classes. Personally, I find Haskell's restriction counter-intuitive but the sense of surprise and limitation is diminishing as I use the language.

Right, I like this point. I don't like to think of Haskell type-classes as Java interfaces, even though I came from a C++/Java background. First and foremost, I like to think of type-classes as a way to do operator overloading, and after that I start thinking about all the other things you can do with them. Java interfaces don't smell much like type-classes to me. First of all, when you call a method on an object in Java whose type is given by an interface, you can't generally tell which implementing method will be called: it depends on the runtime type of the object (dynamic dispatch, in other words). Haskell 98 type-classes don't have this property. The thing to note is that Java interfaces allow you to assign multiple types to the same value. Every value has the type of its class, but then it also gets the type of any interfaces it happens to implement. But, in Haskell, every value has exactly *one* type. That's why you can't mix and match them in a collection. And it's why you can determine at compiletime rather than runtime which implementation of a typeclass will be used at which points of the code. Some of the things you would do with Java interfaces would be done in other ways in Haskell, using higher-order functions and algebraic data-types, so that's another reason not to think too heavily about interfaces when approaching Haskell. In general, I find it doesn't help me or help my friends when they try to map ideas from languages like Java into Haskell. They end up writing non-idiomatic Haskell programs. Like I say, I think the first place to start when trying to understand type-classes is to think about operator overloading. This is a familiar idea in programming, and type-classes were invented initially to solve it.

Cheers, Bob

[1] -- http://www.haskell.org/haskellwiki/Heterogenous_collections#Existential_type... [2] -- https://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-...

...

[1] - http://www.haskell.org/tutorial/classes.html

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners