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