• Simon Peyton Jones's avatar
    Major patch to introduce TyConBinder · e368f326
    Simon Peyton Jones authored
    Before this patch, following the TypeInType innovations,
    each TyCon had two lists:
      - tyConBinders :: [TyBinder]
      - tyConTyVars  :: [TyVar]
    
    They were in 1-1 correspondence and contained
    overlapping information.  More broadly, there were many
    places where we had to pass around this pair of lists,
    instead of a single list.
    
    This commit tidies all that up, by having just one list of
    binders in a TyCon:
    
      - tyConBinders :: [TyConBinder]
    
    The new data types look like this:
    
      Var.hs:
         data TyVarBndr tyvar vis = TvBndr tyvar vis
         data VisibilityFlag = Visible | Specified | Invisible
         type TyVarBinder = TyVarBndr TyVar VisibilityFlag
    
      TyCon.hs:
         type TyConBinder = TyVarBndr TyVar TyConBndrVis
    
         data TyConBndrVis
           = NamedTCB VisibilityFlag
           | AnonTCB
    
      TyCoRep.hs:
         data TyBinder
           = Named TyVarBinder
           | Anon Type
    
    Note that Var.TyVarBdr has moved from TyCoRep and has been
    made polymorphic in the tyvar and visiblity fields:
    
         type TyVarBinder = TyVarBndr TyVar VisibilityFlag
            -- Used in ForAllTy
         type TyConBinder = TyVarBndr TyVar TyConBndrVis
            -- Used in TyCon
    
         type IfaceForAllBndr  = TyVarBndr IfaceTvBndr VisibilityFlag
         type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis
             -- Ditto, in interface files
    
    There are a zillion knock-on changes, but everything
    arises from these types.  It was a bit fiddly to get the
    module loops to work out right!
    
    Some smaller points
    ~~~~~~~~~~~~~~~~~~~
    * Nice new functions
        TysPrim.mkTemplateKiTyVars
        TysPrim.mkTemplateTyConBinders
      which help you make the tyvar binders for dependently-typed
      TyCons.  See comments with their definition.
    
    * The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code
      was making an assumption about the order of the kind variables in the
      kind of GHC.Generics.(:.:).  I fixed this; see TcGenGenerics.mkComp.
    e368f326
TcSigs.hs 28.6 KB