That was quite a satisfying explanation, thank you. That is certainly
clearing a few things up.
Sean
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, December 26, 2003 3:07 AM
Subject: Re: Haskell naming conventions
> 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
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
