From f7e4ca26a0a91265573ea05ee46143787ace82f8 Mon Sep 17 00:00:00 2001
From: simonpj <unknown>
Date: Wed, 11 Dec 2002 17:09:08 +0000
Subject: [PATCH] [project @ 2002-12-11 17:09:08 by simonpj] Back out the
 function tycon kind change (big comment to explain why)

---
 ghc/compiler/types/TypeRep.lhs |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/ghc/compiler/types/TypeRep.lhs b/ghc/compiler/types/TypeRep.lhs
index 1ea81e7..c8e9f46 100644
--- a/ghc/compiler/types/TypeRep.lhs
+++ b/ghc/compiler/types/TypeRep.lhs
@@ -364,8 +364,14 @@ instance Binary Kind where
 We define a few wired-in type constructors here to avoid module knots
 
 \begin{code}
-funTyCon = mkFunTyCon funTyConName (mkArrowKinds [openTypeKind, openTypeKind] liftedTypeKind)
-	-- Functions can take and return either lifted or unlifted types
+funTyCon = mkFunTyCon funTyConName (mkArrowKinds [liftedTypeKind, liftedTypeKind] liftedTypeKind)
+	-- You might think that (->) should have type (? -> ? -> *), and you'd be right
+	-- But if we do that we get kind errors when saying
+	--	instance Control.Arrow (->)
+	-- becuase the expected kind is (*->*->*).  The trouble is that the
+	-- expected/actual stuff in the unifier does not go contra-variant, whereas
+	-- the kind sub-typing does.  Sigh.  It really only matters if you use (->) in
+	-- a prefix way, thus:  (->) Int# Int#.  And this is unusual.
 \end{code}
 
 ------------------------------------------
-- 
1.7.10.4