"Cagdas Ozgenc" writes:

class Eq a where

    (==) :: a -> a -> Bool

Why do we conlude that both of the "a" refer to the same type?

Because they have the same name? I'm sorry, but I don't think I follow you.

Apparently using different types that both belonging to class Eq results in an error. For example

65 == 'a'

Yeah, that won't work. I belive the vernacular term is "apples and oranges".

It doesn't make much sense at first, however, how do you go by implementing multiple polymorphism?

There's an extension, try e.g. ghc -fglasgow-exts (IIRC). Then you can do class Foo a b where foo :: a -> b -> Bool instance Foo Char Int where foo x y = if Char.ord x == y then True else False

Secondly, why does Haskell distinguish between a Type and a Class? There seems to be no benefit of such approach.

Say what? Types are created with the 'data' keyword, and what follows is the definition of the data type. Classes describe properties types can have (or possible relationships betwen types), and instances are concrete declarations of types having those properties. Think of it as the equivalent to 'class' and 'interface' in Jave, concrete and abstract classes in C++. Or if you're familiar with generic programming, e.g. in CLOS, that's close to what you've got here.

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

My dictionary fails me. What did you want to do? Probably not - a class is something that exists at compile time, the Haskell type system doesn't really support run-time typing stuff. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

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.

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

...

class Ord a where    (<) :: a -> a -> Bool

data Set a = Ord a => [...]

The only thing that bothers me here is the Asymmetry. The syntax treats the first, and the second argument differently.

Not really, except for the order not being commutative (same as in C++).

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.

I don't know if I follow your exact concern. In any case, I just thought that you can always do in Haskell something like this: equals :: (Eq a, Eq b) => a -> b -> Bool a ´equals´ b = [...] -- I don't know how to implement this which is something like what you want, except that the definition that you put on that function MUST serve for all appropriate types. In Haskell, you can't add overloads to a function unless that function belongs to a class. Then you can make overloads by making different instances of that class. That has trade-offs over the C++ system, like: - Code is more organized the Haskell way. Easier on the compiler tools. - Programs and modules are more predictable in Haskell, because what they define cannot be 'modified'. - C++ allows dynamic inheritance, which is best in some situations. In Haskell you have to hack it in. - C++ has more flexible static overloading. What can I say? My favorite programming language hasn't been invented yet. But I'm sure it'll borrow concepts from both, Haskel and C++. I like Patrick's little talk about concepts a lot better than anything I said, BTW. It's like the GCC extension of signatures, in a way. Salutaciones, JCAB email: jcab@roningames.com ICQ: 101728263 The Rumblings are back: http://www.JCABs-Rumblings.com