Frank, Then we do mean the same thing, because a relation is indeed a subset of a cartesian product ;-) That is what I meant with "cartesian classes". Sorry for any confusion that might have caused. And, I am fully aware that most people in this mail group are quite familiar with simple set-theoretic concepts, but since the question was raised, and I know that there are a few more pragmatic programmers aboard, I assumed it would not hurt to explain that a bit. I still think "multi-parameter classes" is bad terminology, though, since the subconstruct "C a b" in the class declaration "class C a b where ..." does not denote a class (template), but the "C" does... This is in contrast to "multi-parameter types", such as "data Tree a b = Leaf a | Branch b (Tree a b) (Tree a b)" where the subconstruct "Tree a b" does denote a type (template). Maybe I am the only one with this view... Thanks for the concrete usage info for functional dependencies restricting these "class relations". David -----Original Message----- From: Frank Atanassow [mailto:franka@cs.uu.nl] Sent: Wednesday, November 27, 2002 10:15 AM To: David Bergman Subject: Re: "cartesian classes" David Bergman wrote (on 26-11-02 13:18 -0500):

...

What do you mean by "cartesian classes"? Do you mean multi-parameter type classes?

...

They're supported by GHC and Hugs, but not NHC98 or HBC. The same goes for functional dependencies.

Yes, I meant what is commonly known as multi-parameter type classes, although that name IMHO does not make much sense, since only the explicitly parameterized type class should qualify as a any-parameter type class, with the (non-Haskell syntax) "b in C a", where "a" is the parameter, "C a" the resulting type class, and, finally, "b" the (type) element of the class.

In a regular class declaration, "C a", I would argue that "C" is the class, not being single-parameter, but zero-parameter. It is sometimes unfortunate that the syntax of Haskell makes this look like a constructor...

I'm afraid I don't understand this. If it helps, the way I think of classes is that they are predicates/relations at the type level; a multi-parameter class gives an n-ary predicate for n>1. So, in: class C a b c where ... C is a ternary predicate and instance C Int Char Int where ... says that (Int, Char, Int) is a member of C regarded as a subset of a product of sets.

What I meant by cartesian is that using several variables, you would get (also in non-Haskell syntax) "(a, b, c) in C", i.e., the class actually being a subclass of the third cartesian power of the universal (implicit) type class.

Yes, I know what cartesian products, categories and coordinate systems are, but I've never heard multi-parameter type classes referred to that way before.

If both GHC and Hugs support functional dependencies, I would probably dare to wander off into the mysterious land of Haskell 2.

A very concrete, but naïve, question: what is the syntax for defining functional dependencies in Hugs and GHC? Since Mark Jones' syntax was abstract in his paper, it is kind of hard to deduce an ASCII equivalence (I have tried to figure out how to create a curly arrow from the keyboard ;-)

The syntax is, for example: class Class a b c d | a c -> b d where ... meaning that a and c determine b and d, so if the declaration instance Class A B C D is in scope, then, for all B', D' s.t. B'/=B or D'/=D, it is illegal for there to be a declaration of the form instance Class A B' C D' also in scope. There is an account of the syntax and semantics in the Hugs manual, 7.1.1.3: http://cvs.haskell.org/Hugs/pages/hugsman/exts.html -- Frank