Merge branch 'master' of http://darcs.haskell.org/ghc into ghc-generics

[ghc-hetmet.git] / compiler / types / TyCon.lhs

diff --git a/compiler/types/TyCon.lhs b/compiler/types/TyCon.lhs
index 2350973..0baa312 100644 (file)
--- 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)
@@ -582,7 +595,7 @@ data CoTyConDesc
 
 Note [Enumeration types]
 ~~~~~~~~~~~~~~~~~~~~~~~~
-We define datatypes with no constructors to not be
+We define datatypes with no constructors to *not* be
 enumerations; this fixes trac #2578,  Otherwise we
 end up generating an empty table for
   <mod>_<type>_closure_tbl
@@ -590,6 +603,16 @@ 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)
@@ -1064,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