G'day all. Quoting Lennart Augustsson <[EMAIL PROTECTED]>:
> According to dictionary.com one of the definitions of the word class is: > > A set, collection, group, or configuration containing members regarded > as having certain attributes or traits in common; a kind or category. > > And what the members of class Eq have in common is that they have a > function (==). So to me it seems that the word "class" is very well > chosen; it describes what's going on. Right. It's exactly the same way that Java and C++ use the word "class". A class is a set of types. In the case of Eq, it's the set of types which support the equality testing operation (==). The problem is that C++ (and Java, but I'll use C++ as the archetype from now on) uses the one keyword, "class" to do multiple tasks. When you declare a C++ class: class Foo { // something }; you're actually doing three things. You are defining a class of types, namely, the set of types which are derived (possibly in zero steps) from Foo. You are also defining a concrete type, namely Foo. Finally, you are declaring that the concrete type Foo is a member of the class Foo. Haskell decouples these three tasks. To define a class, you use "class". To define a concrete type you use "data". To declare that a certain concrete type is a member of a class, you use "instance". I should point out that C++ has an idiom something like Haskell type classes, which is the "concept". Concepts are, I think, an admission that OO derivation is often not the most appropriate way to implement an abstract interface. Concepts are not statically checked by default, but there are good libraries out there which effectively provide static checking of concepts. A good C++ programmer would probably not implement Eq as a C++ class because (as Haskell programmers already know), Eq doesn't make sense as a Liskov-substitutable concrete type on its own. Rather, a good C++ programmer would provide the interface for the STL "equality comparable concept", which is pretty much the same as Eq. > Now, I admit that if you think you can take concepts with similar names > from other programming languages and apply them to Haskell you might > get confused. You might come across what is called "false friends" in > natural language, i.e., words that look the same but mean different > things. Well, in this case, what Haskell calls a "class" is a strict subset of what C++ calls a "class", so it's more of a true friend than a false one. It's C++'s fault (though it is historically understandable) that the "class" keyword does more than just declare a class of types. Cheers, Andrew Bromage _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell