Hello Gabriel, Tuesday, August 15, 2006, 10:36:28 PM, you wrote:

| Moreover, Haskell type classes supports inheritance. Run-time | polymorphism together with inheritance are often seen as OOP | distinctive points, so during long time i considered type classes as a | form of OOP implementation. but that's wrong! Haskell type classes | build on different basis, so they are like C++ templates with added | inheritance and run-time polymorphism! And this means that usage of | type classes is different from using classes, with its own strong and | weak points.

Roughly Haskell type classes correspond to parameterized abstract classes in C++ (i.e. class templates with virtual functions representing the operations). Instance declarations correspond to derivation and implementations of those parameterized classes.

i can't agree. the differences between TC inheritance/polymorphism and C++ classes are substantial. i listed them in next part of tutorial which you should see alongside this message. you can also see paper at http://homepages.cwi.nl/~ralf/gpce06/ which is all about consequences of differences between classes and type classes for software development -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Tue, Aug 15, 2006 at 08:36:28PM +0200, Gabriel Dos Reis wrote:

Roughly Haskell type classes correspond to parameterized abstract classes in C++ (i.e. class templates with virtual functions representing the operations). Instance declarations correspond to derivation and implementations of those parameterized classes.

There is a major difference though, in C++ (or java, or sather, or c#, etc..) the dictionary is always attached to the value, the actual class data type you pass around. in haskell, the dictionary is passed separately and the appropriae one is infered by the type system. C++ doesn't infer, it just assumes everything will be carying around its dictionary with it. this makes haskell classes signifigantly more powerful in many ways. class Num a where (+) :: a -> a -> a is imposible to express in OO classes, since both arguments to + necessarily carry their dictionaries with them, there is no way to statically guarentee they have the same one. Haskell will pass a single dictionary that is shared by both types so it can handle this just fine. in haskell you can do class Monoid a where mempty :: a in OOP, this cannot be done because where does the dicionary come from? since dictionaries are always attached to a concrete class, every method must take at least one argument of the class type (in fact, exactly one, as I'll show below). In haskell again, this is not a problem since the dictionary is passed in by the consumer of 'mempty', mempty need not conjure one out of thin air. In fact, OO classes can only express single parameter type classes where the type argument appears exactly once in strictly covariant position. in particular, it is pretty much always the first argument and often (but not always) named 'self' or 'this'. class HasSize a where getSize :: a -> Int can be expressed in OO, 'a' appears only once, as its first argument. Now, another thing OO classes can do is they give you the ability to create existential collections (?) of objects. as in, you can have a list of things that have a size. In haskell, the ability to do this is independent of the class (which is why haskell classes can be more powerful) and is appropriately named existential types. data Sized = exists a . HasSize a => Sized a what does this give you? you can now create a list of things that have a size [Sized] yay! and you can declare an instance for sized, so you can use all your methods on it. instance HasSize Sized where getSize (Sized a) = a an exisential, like Sized, is a value that is passed around with its dictionary in tow, as in, it is an OO class! I think this is where people get confused when comparing OO classes to haskell classes. _there is no way to do so without bringing existentials into play_. OO classes are inherently existential in nature. so, an OO abstract class declaration declares the equivalent of 3 things in haskell: a class to establish the mehods, an existential type to carry the values about, and an instance of the class for the exisential type. an OO concrete class declares all of the above plus a data declaration for some concrete representation. OO classes can be perfectly (even down to the runtime representation!) emulated in Haskell, but not vice versa. since OO languages tie class declarations to existentials, they are limited to only the intersection of their capabilities, because haskell has separate concepts for them, each is independently much much more powerful. data CanApply = exists a b . CanApply (a -> b) a (b -> a) is an example of something that cannot be expressed in OO, existentials are limited to having exactly a single value since they are tied to a single dictionary class Num a where (+) :: a -> a -> a zero :: a negate :: a -> a cannot be expressed in OO, because there is no way to pass in the same dicionary for two elements, or for a returning value to conjure up a dictionary out of thin air. (if you are not convinced, try writing a 'Number' existential and making it an instance of Num and it will be clear why it is not possible) negate is an interesting one, there is no technical reason it cannot be implemented in OO languages, but none seem to actually support it. so, when comparing, remember an OO class always cooresponds to a haskell class + a related haskell existential. incidentally, an extension I am working on is to allow data Sized = exists a . HasSize a => Sized a deriving(HasSize) which would have the obvious interpretation, obviously it would only work under the same limitations as OO classes have, but it would be a simple way for haskell programs to declare OO style classes if they so choose. (actually, it is still signifigantly more powerful than OO classes since you can derive many instances, and even declare your own for classes that don't meet the OO consraints, also, your single class argument need not appear as the first one. it can appear in any strictly covarient position, and it can occur as often as you want in contravariant ones!) John [1] exists is called forall in ghc

-- Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- John Meacham - ⑆repetae.net⑆john⑈

Hello Thomas, Friday, August 18, 2006, 7:57:13 AM, you wrote:

...

There is a major difference though, in C++ (or java, or sather, or c#, etc..) the dictionary is always attached to the value, the actual class data type you pass around. in haskell, the dictionary is passed separately and the appropriae one is infered by the type system. C++ doesn't infer, it just assumes everything will be carying around its dictionary with it.

C++ programmers deal with this using a number of techniques, mostly involving templates.

Haskell type classes are closer to templates/generics than to classes itself

Actually, there is one technique using C++ templates that I really want to see going mainstream in the Haskell implementations. Existential types are already there, now I want to see associated types (trait types in C++). Maybe I've been doing too much C++ programming in the last few years, but a lot of the times when I end up using multiparameter type classes, what I really want is an associated type.

i also wrote a lot of such code for Streams library and can say that MPTC+FD are close enough to emulate AT, although need slightly more verbose definitions. moreover, AT are already implemented in GHC 6.5, afai seen in ghc-cvs reports

For those who are interested, I'm sure the relevant papers are readily available on citeseer/Google. :-)

http://haskell.org/haskellwiki/Research_papers/Type_systems#Associated_types -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hello John, Friday, August 18, 2006, 5:16:45 AM, you wrote:

There is a major difference though, in C++ (or java, or sather, or c#, etc..) the dictionary is always attached to the value, the actual class data type you pass around. in haskell, the dictionary is passed separately and the appropriae one is infered by the type system.

your letter is damn close to that i wrote in http://haskell.org/haskellwiki/OOP_vs_type_classes although i mentioned not only pluses but also drawbacks of type classes: lack of record extension mechanisms (such at that implemented in O'Haskell) and therefore inability to reuse operation implementation in an derived data type, lack of downcasting mechanism (which bites me all the way), requirement to rebuild dictionaries in polymorphic operations what is slow enough i will put your letter there and later use it to build up the final description, ok? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hello Brian, Friday, August 18, 2006, 8:54:08 PM, you wrote:

...

http://haskell.org/haskellwiki/OOP_vs_type_classes although i mentioned not only pluses but also drawbacks of type classes: lack of record extension mechanisms (such at that implemented in O'Haskell) and therefore inability to reuse operation implementation in an derived data type...

You can reuse ops in a derived data type but it involves a tremendous amount of boilerplate.

of course, but it's just OOP emulation. one can do the same in C, for example. i've added your letter to the page. but anyway, one of key OOP ideas was extensible records, it was idea what distinguished OOP from abstract data types approach -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Bulat Ziganshin writes: | Hello John, | | Friday, August 18, 2006, 5:16:45 AM, you wrote: | | > There is a major difference though, in C++ (or java, or sather, or c#, | > etc..) the dictionary is always attached to the value, the actual class | > data type you pass around. in haskell, the dictionary is passed | > separately and the appropriae one is infered by the type system. | | your letter is damn close to that i wrote in | http://haskell.org/haskellwiki/OOP_vs_type_classes | although i mentioned not only pluses but also drawbacks of type | classes: lack of record extension mechanisms (such at that implemented | in O'Haskell) and therefore inability to reuse operation | implementation in an derived data type, lack of downcasting mechanism | (which bites me all the way), requirement to rebuild dictionaries in | polymorphic operations what is slow enough I would appreciate if you could revise the comparison based on the material I just sent, that illustrates my earlier comments.

Hello Gabriel, Sunday, August 20, 2006, 8:26:30 AM, you wrote:

| There is a major difference though, in C++ (or java, or sather, or c#, | etc..) the dictionary is always attached to the value, the actual class | data type you pass around.

The dictionary can be attached to the operations (not just to the values) by using objects local to functions (which sort of matierialize the dictionary).

This means that type classes can be _emulated_ in C++. but the bare semantics is just as we said - in Haskell dictionaries are passed around the functions (unless existential used) and in C++ they are attached to objects i agree that emulation you provided is closer to type classes at least in that it implements _dynamic_ dispatching vs compile-time dispatching of templates. but typical C++ programming involves using classes and templates, not the unusual technique you have introduced. please note that one can also use some other technique (say, function pointers or switch statements) to emulate type classes behavior and this don't means that switch statements in C is a kind of type classes :) my comparison was targeted to teaching Haskell newbies (especially former OOP programmers) how to use type classes, give them a _intuition_ of this language feature and directions about its usage. C++ templates with their type inference and dispatch based on the type of entire operation is a best approximation in OOP world i know but (of course) i will add your letter as one more description of that type classes are, at this time - in terms of emulation them in C++ (in addition to emulation them in Haskell, written by Wadler and Blott) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

I was mainly specifically comparing haskell to standard OOP classes, Most OOP languages certainly have some set of other features in addition, such as forms of ad hoc polymorphism or the template meta-language of C++, or the code reuse primitives in sather, however I was mainly interested in exploring base OOP and its relation to haskell typeclasses. As it seems to come up a lot. C++ templates are a whole nother ball of wax. John -- John Meacham - ⑆repetae.net⑆john⑈

John Meacham writes: | I was mainly specifically comparing haskell to standard OOP classes, | | Most OOP languages certainly have some set of other features in addition, | such as forms of ad hoc polymorphism or the template meta-language of | C++, or the code reuse primitives in sather, however I was mainly | interested in exploring base OOP and its relation to haskell | typeclasses. As it seems to come up a lot. | | C++ templates are a whole nother ball of wax. I believe you should not eliminate C++ templates from "standard OO" classes -- for example, the C++ IOStream hierarchy is an example of "standard OO" -- at least if you want to discuss "OOP" with C++ :-)