Haskell naming conventions

[ajb at spamcop.net]

G'day all.

Quoting Lennart Augustsson <lennart at augustsson.net>:

> 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