On 23-Dec-2003, Sean L. Palmer <seanpalmer@verizon.net> wrote:
It occurs to me that Haskell would be quite a bit easier for OO and traditional programmers to grasp if Haskell would actually use the correct, or at least more commonly used, names for things.
For instance,
data Maybe a = Nothing | Just a
Maybe is a type constructor and Nothing and Just are data constructors.
So it makes me wonder why the use of the data keyword... wouldn't it make more sense to say:
type Maybe a = Nothing | Just a
?
I agree. That's one of the reasons why Mercury uses the word "type" rather than "data" when declaring discriminated union types. The corresponding declaration in Mercury is :- type maybe(A) ---> nothing ; just(A).
Likewise with class, type class, and instance:
class Eq a where (==) :: a -> a -> Bool
That actually declares a type class, not a class. So why the use of the keyword class? Is it done merely to confuse C++ and Java programmers?
This is indeed potentially confusing for programmers familiar with C++/Java/C#/Ada/etc. In Mercury, we adopted Haskell-style type classes, using semantics very similar to those in Haskell. But we did adapt the syntax a bit. In particular, we use "typeclass" rather than "class" for type class declarations. So in Mercury, the corresponding declaration would look like this: :- typeclass eq(A) where [ func '=='(A, A) = bool ].
The concept of type class in Haskell apparently roughly corresponds to the concept of "interface" in Java. So why not call it interface?
Haskell interfaces are really quite a bit more general than Java interfaces, particularly when you consider common extensions such as multi-parameter type classes, constructor classes, and functional dependencies. So I think it would not help to use the word "interface". -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.