classes

[Cagdas Ozgenc]

Hi,


>   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
myself.
>

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
concerned.

>>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
implementations.

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

>>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.