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:[EMAIL PROTECTED]] 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 _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell