Cagdas Ozgenc
Fri, 31 Aug 2001 22:24:06 +0300


>   One advantage is that, in Haskell, you can specifically assert for
instances of classes, while in C++ you have to rely in >compiler errors that
can be disorienting at times. For example, std::set<val> requires that the
parameter type have a '<' >operator, but you can't assert on it. In Haskell
you can, using contexts:

Right. I have been thinking about this. C++ has the concept of "this" but
not "this & that". What I am trying to say is "<" operation works on 2
objects, but all C++ member functions act on a single object. Therefore you
cannot force implementation of "<" by declaring it in a base class, because
it requires a larger schema scope than a single class.

>class Ord a where
>   (<) :: a -> a -> Bool
>data Set a = Ord a => [...]
>   I don't know if I'm making sense. I'm not that proficient in Haskell

The only thing that bothers me here is the Asymmetry. The syntax treats the
first, and the second argument differently. Although there is equal emphasis
on both "a"s in an "<" operation. C++ solves this problem by taking them out
of the class.

bool operator < (const Ord& a, const Ord& b);

where arguments are treated with equal rights. Maybe I am just too

>>Secondly, why does Haskell distinguish between a Type and a Class?
>>There seems to be no benefit of such approach.
>   Oh, there's benefit. It does require a serious change in perspective,
though. It can't be so easily explained.

One benefit I see here is that I can make the type member of other classes
afterwards, whereas in C++ you have to specify the base-classes beforehand.

What again bothers me here that the global functions that are defined over
the type. Therefore there is a class, but Implicitly!!
IMHO, a type is actually a class. What I am trying to say is:

a type + global functions over the type = a class

Let's say there is a type called Book.

Now drop all global functions asociated with Book. Then create a class
BookImpl. Move those functions inside that class. Then make Book an instance
of BookImpl. Now, at least other classes have the option of overriding the

Hence, I cannot see why there is a need for distinguishing a type and a

>>Thirdly, is it possible to define meta-classes in Haskell.

Oh OK. I now read it in my book. What I had in mind was parameterized types.

Thanks for taking time.