"cartesian classes"

[David Bergman]

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 =3D =
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]=20
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?
>=20
> > They're supported by GHC and Hugs, but not NHC98 or HBC. The same
goes
> > for functional dependencies.
>=20
> 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.
>=20
> 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.
>=20
> A very concrete, but na=EFve, 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'/=3DB or D'/=3DD, 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

--=20
Frank