X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=compiler%2Ftypes%2FTyCon.lhs;h=0baa312e99633527a56541208ff347fbf533a9af;hb=c9d713bca9ce31fed25d7201464bad48f0dbc647;hp=e7f8507d81a5aa3749c6d81eacfb6f78f5b771b3;hpb=56a437ee698c5a46864e7fcc530707742589ef7d;p=ghc-hetmet.git diff --git a/compiler/types/TyCon.lhs b/compiler/types/TyCon.lhs index e7f8507..0baa312 100644 --- a/compiler/types/TyCon.lhs +++ b/compiler/types/TyCon.lhs @@ -67,7 +67,7 @@ module TyCon( tyConExtName, -- External name for foreign types algTyConRhs, newTyConRhs, newTyConEtadRhs, unwrapNewTyCon_maybe, - tupleTyConBoxity, + tupleTyConBoxity, tupleTyConArity, -- ** Manipulating TyCons tcExpandTyCon_maybe, coreExpandTyCon_maybe, @@ -129,15 +129,28 @@ Note [Type synonym families] * Translation of type instance decl: type instance F [a] = Maybe a - translates to - A SynTyCon 'R:FList a', whose + translates to a "representation TyCon", 'R:FList', where + R:FList is a SynTyCon, whose SynTyConRhs is (SynonymTyCon (Maybe a)) TyConParent is (FamInstTyCon F [a] co) where co :: F [a] ~ R:FList a - Notice that we introduce a gratuitous vanilla type synonym + + It's very much as if the user had written + type instance F [a] = R:FList a type R:FList a = Maybe a - solely so that type and data families can be treated more - uniformly, via a single FamInstTyCon descriptor + Indeed, in GHC's internal representation, the RHS of every + 'type instance' is simply an application of the representation + TyCon to the quantified varaibles. + + The intermediate representation TyCon is a bit gratuitous, but + it means that: + + each 'type instance' decls is in 1-1 correspondance + with its representation TyCon + + So the result of typechecking a 'type instance' decl is just a + TyCon. In turn this means that type and data families can be + treated uniformly. * In the future we might want to support * closed type families (esp when we have proper kinds) @@ -440,7 +453,7 @@ data AlgTyConRhs -- (see the tag assignment in DataCon.mkDataCon) is_enum :: Bool -- ^ Cached value: is this an enumeration type? - -- (See 'isEnumerationTyCon') + -- See Note [Enumeration types] } -- | Information about those 'TyCon's derived from a @newtype@ declaration @@ -580,6 +593,26 @@ data CoTyConDesc | CoUnsafe \end{code} +Note [Enumeration types] +~~~~~~~~~~~~~~~~~~~~~~~~ +We define datatypes with no constructors to *not* be +enumerations; this fixes trac #2578, Otherwise we +end up generating an empty table for + __closure_tbl +which is used by tagToEnum# to map Int# to constructors +in an enumeration. The empty table apparently upset +the linker. + +Moreover, all the data constructor must be enumerations, meaning +they have type (forall abc. T a b c). GADTs are not enumerations. +For example consider + data T a where + T1 :: T Int + T2 :: T Bool + T3 :: T a +What would [T1 ..] be? [T1,T3] :: T Int? Easiest thing is to exclude them. +See Trac #4528. + Note [Newtype coercions] ~~~~~~~~~~~~~~~~~~~~~~~~ The NewTyCon field nt_co is a a TyCon (a coercion constructor in fact) @@ -983,6 +1016,7 @@ isGadtSyntaxTyCon _ = False -- | Is this an algebraic 'TyCon' which is just an enumeration of values? isEnumerationTyCon :: TyCon -> Bool +-- See Note [Enumeration types] in TyCon isEnumerationTyCon (AlgTyCon {algTcRhs = DataTyCon { is_enum = res }}) = res isEnumerationTyCon (TupleTyCon {tyConArity = arity}) = arity == 0 isEnumerationTyCon _ = False @@ -1053,6 +1087,11 @@ isBoxedTupleTyCon _ = False tupleTyConBoxity :: TyCon -> Boxity tupleTyConBoxity tc = tyConBoxed tc +-- | Extract the arity of the given 'TyCon', if it is a 'TupleTyCon'. +-- Panics otherwise +tupleTyConArity :: TyCon -> Arity +tupleTyConArity tc = tyConArity tc + -- | Is this a recursive 'TyCon'? isRecursiveTyCon :: TyCon -> Bool isRecursiveTyCon (AlgTyCon {algTcRec = Recursive}) = True