Haskell naming conventions

[Sean L. Palmer]

That was quite a satisfying explanation, thank you.  That is certainly
clearing a few things up.

Sean

----- Original Message ----- 
From: <ajb at spamcop.net>
To: <haskell at haskell.org>
Sent: Friday, December 26, 2003 3:07 AM
Subject: Re: Haskell naming conventions


> 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
> _______________________________________________
> Haskell mailing list
> Haskell at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell