\begin{code}
module TypeRep (
- Type(..), TyNote(..), PredType(..), -- Representation visible to friends
+ Type(..), TyNote(..), -- Representation visible
+ SourceType(..), -- to friends
- Kind, ThetaType, RhoType, TauType, SigmaType, -- Synonyms
+ Kind, PredType, ThetaType, -- Synonyms
TyVarSubst,
superKind, superBoxity, -- KX and BX respectively
#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,
( a, b ) No Yes Yes Yes
[a] No Yes Yes Yes
+
+
+ ----------------------
+ A note about newtypes
+ ----------------------
+
+Consider
+ newtype N = MkN Int
+
+Then we want N to be represented as an Int, and that's what we arrange.
+The front end of the compiler [TcType.lhs] treats N as opaque,
+the back end treats it as transparent [Type.lhs].
+
+There's a bit of a problem with recursive newtypes
+ newtype P = MkP P
+ newtype Q = MkQ (Q->Q)
+
+Here the 'implicit expansion' we get from treating P and Q as transparent
+would give rise to infinite types, which in turn makes eqType diverge.
+Similarly splitForAllTys and splitFunTys can get into a loop.
+
+Solution: for recursive newtypes use a coerce, and treat the newtype
+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}
TyVar
Type
- | PredTy -- A Haskell predicate
- PredType
-
- | UsageTy -- A usage-annotated type
- Type -- - Annotation of kind $ (i.e., usage annotation)
- Type -- - Annotated type
+ | SourceTy -- A high level source type
+ SourceType -- ...can be expanded to a representation type...
| NoteTy -- A type with a note attached
TyNote
Type -- The expanded version
data TyNote
- = SynNote Type -- The unexpanded version of the type synonym; always a TyConApp
- | FTVNote TyVarSet -- The free type variables of the noted expression
+ = FTVNote TyVarSet -- The free type variables of the noted expression
-type ThetaType = [PredType]
-type RhoType = Type
-type TauType = Type
-type SigmaType = Type
-\end{code}
+ | 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.
-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}
-------------------------------------
- Predicates
+ Source types
+
+A type of the form
+ SourceTy sty
+represents a value whose type is the Haskell source type sty.
+It can be expanded into its representation, but:
+
+ * The type checker must treat it as opaque
+ * The rest of the compiler treats it as transparent
+
+There are two main uses
+ a) Haskell predicates
+ b) newtypes
Consider these examples:
f :: (Eq a) => a -> Int
Predicates are represented inside GHC by PredType:
\begin{code}
-data PredType = ClassP Class [Type]
- | IParam Name Type
+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]
\end{code}
(We don't support TREX records yet, but the setup is designed
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
\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}
------------------------------------------
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}
%************************************************************************
%* *
\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}
------------------------------------------
projects / ghc-hetmet.git / blobdiff