A type is a set of values (constructors):
data Type = Constr1 | Constr2 | Constr3
likewise a class is a set of types (IE we lift one level)
class Class instance Class Type1 instance Class Type2 instance Class Type3
So types are to classes as values are to types... this makes classes roughly equivalent to type-families.
We can extend this indefinitely as long as we observe the russell-paradox (that is
a set can only refer to values at a lower level...). So we could have a set of classes (which I am not aware of a name for...)
Of course this makes the naming etc. used in Haskell look very ad-hoc, wouldn't it be nice if you could freely mix constructs from different levels, so for example you could have a function that takes a class and a value and returns a type...
Keean.
Robert Dockins wrote:
On Sat, 2005-03-05 at 00:25 +0100, Benjamin Franksen wrote:
OK, I can see now that this makes sense syntactically. Still, it is
strange that the class name is handled as if it were a type constructor.
Yes. It makes a weird sort of sense if you pretend type classes are actually type constructors and instance declarations are inhabited by types in a new "type class kind". Say we use the symbol 'C' for the kind of type class types. Then the usual single parameter type class constructors would have kind (* -> C) and multiparameter classes just have more arrows, al la (* -> * -> C) for 2 parameters.
I can't decide if I like this idea or not. Does it have any validity in
the associated type or category theories?
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
