X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=ghc%2Fcompiler%2Ftypes%2FTypeRep.lhs;h=1bb3479ee6a30ee7ae3eea04a4563cd973eba577;hb=33fec6b1cf3efcc80f4ba9e4f81920fb67bb0beb;hp=a00b86f6280d47ddfd5798cc9bc962312e5417f8;hpb=d069cec2bd92d4156aeab80f7eb1f222a82e4103;p=ghc-hetmet.git diff --git a/ghc/compiler/types/TypeRep.lhs b/ghc/compiler/types/TypeRep.lhs index a00b86f..1bb3479 100644 --- a/ghc/compiler/types/TypeRep.lhs +++ b/ghc/compiler/types/TypeRep.lhs @@ -5,9 +5,10 @@ \begin{code} module TypeRep ( - Type(..), TyNote(..), SourceType(..), -- Representation visible to friends + Type(..), TyNote(..), -- Representation visible + SourceType(..), -- to friends - Kind, TauType, PredType, ThetaType, -- Synonyms + Kind, PredType, ThetaType, -- Synonyms TyVarSubst, superKind, superBoxity, -- KX and BX respectively @@ -28,13 +29,14 @@ module TypeRep ( #include "HsVersions.h" -- friends: -import Var ( TyVar ) -import VarEnv -import VarSet - -import Name ( Name ) -import TyCon ( TyCon, KindCon, mkFunTyCon, mkKindCon, mkSuperKindCon ) -import Class ( Class ) +import Var ( TyVar ) +import VarEnv ( TyVarEnv ) +import VarSet ( TyVarSet ) +import Name ( Name ) +import BasicTypes ( IPName ) +import TyCon ( TyCon, KindCon, mkFunTyCon, mkKindCon, mkSuperKindCon ) +import Class ( Class ) +import Binary -- others import PrelNames ( superKindName, superBoxityName, liftedConName, @@ -118,10 +120,19 @@ and its representation as distinct right through the compiler. That's what you get if you use recursive newtypes. (They are rare, so who cares if they are a tiny bit less efficient.) +So: non-recursive newtypes are represented using a SourceTy (see below) + recursive newtypes are represented using a TyConApp + 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} @@ -132,7 +143,6 @@ newtype application as a SourceType; instead as a TyConApp. \begin{code} type SuperKind = Type type Kind = Type -type TauType = Type type TyVarSubst = TyVarEnv Type @@ -159,10 +169,6 @@ data Type | SourceTy -- A high level source type SourceType -- ...can be expanded to a representation type... - | UsageTy -- A usage-annotated type - Type -- - Annotation of kind $ (i.e., usage annotation) - Type -- - Annotated type - | NoteTy -- A type with a note attached TyNote Type -- The expanded version @@ -173,12 +179,8 @@ data TyNote | SynNote Type -- Used for type synonyms -- The Type is always a TyConApp, and is the un-expanded form. -- The type to which the note is attached is the expanded form. -\end{code} -INVARIANT: UsageTys are optional, but may *only* appear immediately -under a FunTy (either argument), or at top-level of a Type permitted -to be annotated (such as the type of an Id). NoteTys are transparent -for the purposes of this rule. +\end{code} ------------------------------------- Source types @@ -204,10 +206,11 @@ Here the "Eq a" and "?x :: Int -> Int" and "r\l" are all called *predicates* Predicates are represented inside GHC by PredType: \begin{code} -data SourceType = ClassP Class [Type] -- Class predicate - | IParam Name Type -- Implicit parameter - | NType TyCon [Type] -- A *saturated*, *non-recursive* newtype application - -- [See notes at top about newtypes] +data SourceType + = ClassP Class [Type] -- Class predicate + | IParam (IPName Name) Type -- Implicit parameter + | NType TyCon [Type] -- A *saturated*, *non-recursive* newtype application + -- [See notes at top about newtypes] type PredType = SourceType -- A subtype for predicates type ThetaType = [PredType] @@ -266,8 +269,8 @@ in two situations: type variable, one that may very well later be unified with a type. For example, suppose f::a, and we see an application (f x). Then a must be a function type, so we unify a with (b->c). But what kind - are b and c? They can be lifted or unlifted types, so we give them - kind '?'. + are b and c? They can be lifted or unlifted types, or indeed type schemes, + so we give them kind '?'. When the type checker generalises over a bunch of type variables, it makes any that still have kind '?' into kind '*'. So kind '?' is never @@ -291,9 +294,11 @@ Define boxities: @*@ and @#@ \begin{code} liftedBoxity, unliftedBoxity :: Kind -- :: BX -liftedBoxity = TyConApp (mkKindCon liftedConName superBoxity) [] +liftedBoxity = TyConApp liftedBoxityCon [] +unliftedBoxity = TyConApp unliftedBoxityCon [] -unliftedBoxity = TyConApp (mkKindCon unliftedConName superBoxity) [] +liftedBoxityCon = mkKindCon liftedConName superBoxity +unliftedBoxityCon = mkKindCon unliftedConName superBoxity \end{code} ------------------------------------------ @@ -326,6 +331,29 @@ mkArrowKinds :: [Kind] -> Kind -> Kind mkArrowKinds arg_kinds result_kind = foldr mkArrowKind result_kind arg_kinds \end{code} +----------------------------------------------------------------------------- +Binary kinds for interface files + +\begin{code} +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 + put_ bh (FunTy f a) = do putByte bh 4; put_ bh f; put_ bh a + put_ bh _ = error "Binary.put(Kind): strange-looking Kind" + + get bh = do + 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) +\end{code} %************************************************************************ %* *