X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=ghc%2Fcompiler%2Ftypes%2FTypeRep.lhs;h=7447e88fd65af62057ca63622848ee8cd9d7b409;hb=957bf3756ffd56f5329a2aabe1022d6f996dd641;hp=17ae62fbf921a948a261840860acd72a815f394f;hpb=0171936c9092666692c69a7f93fa75af976330cb;p=ghc-hetmet.git diff --git a/ghc/compiler/types/TypeRep.lhs b/ghc/compiler/types/TypeRep.lhs index 17ae62f..7447e88 100644 --- a/ghc/compiler/types/TypeRep.lhs +++ b/ghc/compiler/types/TypeRep.lhs @@ -18,11 +18,6 @@ module TypeRep ( liftedTypeKind, unliftedTypeKind, openTypeKind, -- :: KX mkArrowKind, mkArrowKinds, -- :: KX -> KX -> KX - usageKindCon, -- :: KX - usageTypeKind, -- :: KX - usOnceTyCon, usManyTyCon, -- :: $ - usOnce, usMany, -- :: $ - funTyCon ) where @@ -41,7 +36,6 @@ import Binary -- others import PrelNames ( superKindName, superBoxityName, liftedConName, unliftedConName, typeConName, openKindConName, - usageKindConName, usOnceTyConName, usManyTyConName, funTyConName ) \end{code} @@ -127,6 +121,12 @@ The TyCon still says "I'm a newtype", but we do not represent the newtype application as a SourceType; instead as a TyConApp. +NOTE: currently [March 02] we regard a newtype as 'recursive' if it's in a +mutually recursive group. That's a bit conservative: only if there's a loop +consisting only of newtypes do we need consider it as recursive. But it's +not so easy to discover that, and the situation isn't that common. + + %************************************************************************ %* * \subsection{The data type} @@ -236,8 +236,6 @@ kind :: KX = kind -> kind | Type liftedness -- (Type *) is printed as just * -- (Type #) is printed as just # - | UsageKind -- Printed '$'; used for usage annotations - | OpenKind -- Can be lifted or unlifted -- Printed '?' @@ -296,7 +294,7 @@ unliftedBoxityCon = mkKindCon unliftedConName superBoxity \end{code} ------------------------------------------ -Define kinds: Type, Type *, Type #, OpenKind, and UsageKind +Define kinds: Type, Type *, Type #, OpenKind \begin{code} typeCon :: KindCon -- :: BX -> KX @@ -309,9 +307,6 @@ unliftedTypeKind = TyConApp typeCon [unliftedBoxity] openKindCon = mkKindCon openKindConName superKind openTypeKind = TyConApp openKindCon [] - -usageKindCon = mkKindCon usageKindConName superKind -usageTypeKind = TyConApp usageKindCon [] \end{code} ------------------------------------------ @@ -332,7 +327,6 @@ Binary kinds for interface files instance Binary Kind where put_ bh k@(TyConApp tc []) | tc == openKindCon = putByte bh 0 - | tc == usageKindCon = putByte bh 1 put_ bh k@(TyConApp tc [TyConApp bc _]) | tc == typeCon && bc == liftedBoxityCon = putByte bh 2 | tc == typeCon && bc == unliftedBoxityCon = putByte bh 3 @@ -343,7 +337,6 @@ instance Binary Kind where b <- getByte bh case b of 0 -> return openTypeKind - 1 -> return usageTypeKind 2 -> return liftedTypeKind 3 -> return unliftedTypeKind _ -> do f <- get bh; a <- get bh; return (FunTy f a) @@ -359,19 +352,13 @@ We define a few wired-in type constructors here to avoid module knots \begin{code} 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} ------------------------------------------- -Usage tycons @.@ and @!@ - -The usage tycons are of kind usageTypeKind (`$'). The types contain -no values, and are used purely for usage annotation. - -\begin{code} -usOnceTyCon = mkKindCon usOnceTyConName usageTypeKind -usOnce = TyConApp usOnceTyCon [] - -usManyTyCon = mkKindCon usManyTyConName usageTypeKind -usMany = TyConApp usManyTyCon [] -\end{code}