GHC and Kinds
steffen.mazanek at unibw-muenchen.de
Thu Oct 30 17:21:28 EST 2003
> It means that Kinds are represented by Types.
> Admittedly, Kinds only use a small fragment of what Types can represent,
> namely Arrow, and type constructor applications. So * is represented by
> a TyConApp with a TyCon that is called typeCon.
> The really annoying thing about Kinds is that there's occasionally a bit
> of sub-kinding. In particular
> error :: forall a. String -> a
> We want to allow
> error "foo" :: Int#
I have subkinding in my calculus as well, but in a completely
different context. For instance, the kind of Either is
+ -> + -> * because Either is covariant in its arguments.
But the kind of Either is also x -> x -> * (x=invariance).
So we have + -> + -> * as the most specific kind of Either.
Note, that the kind arrow in my system is contravariant
as well. I think, that is a nice analogy to the type
For example, let tau_1:(x -> *) -> *, tau_2:(+ -> *) -> *.
Then tau_1 is usable whenever tau_2 is in operation.
So from (+ -> *) <: (x -> *) it follows in my system, that
(x -> *) -> * <: (+ -> *) -> *. Unfortunately I have to
decide two contexts of the kind arrow. To understand this,
consider my definition of kinds:
Def.: Kinds are inductively defined as follows:
* is a kind
if kappa1 and kappa2 are kinds, then kappa1 -> kappa2 is a kind
if kappa is a kind, then + -> kappa, - -> kappa, x -> kappa and
alpha -> kappa
alpha is a so-called kind variable, that can be instantiated
by +, - or x (not by arbitrary kinds!). Further on, we have the
convention, that * -> kappa has to be seen as x -> kappa.
What do we mean by the term kind variable?
A type tau may have the kind (alpha->beta->*)->alpha->beta->*. If
one applies this type, e.g., to the arrow type constructor
one gaines (tau (->)): - -> + -> *. So information about variances
is propagated. This allows for subtyping in a convenient manner.
> so the kind of 'a' can't be *, nor # (the kind of unboxed types). It's
> an "open" kind, written "?"; both * and # are sub-kinds of ?.
I have read about this issue in the sources of the GHC. I try to
> You should nevertheless be able to encode your kind system in the same
> way as GHC does.
This is a pity, because my kind system allows for a really
nice type inference algorithm, that can deal with higher-kinded
types properly. I hope, that I can transfer it to the GHC.
I will write a short section for the commentary as soon as
I completely understand the GHC kind system.
> But I have been thinking that it's over-kill to use Types for Kinds, and
> leads to no real saving.
I think so, too, because the system from "Typing Haskell
in Haskell" is very easy to understand and extend. Another
advantage is, that it is closer to the Haskell report.
> I may well split the two types in the future.
This would be great.
Thank you for the informations,
More information about the Haskell