• Ryan Scott's avatar
    Name (tc)SplitForAll- functions more consistently · d61adb3d
    Ryan Scott authored
    There is a zoo of `splitForAll-` functions in `GHC.Core.Type` (as well as
    `tcSplitForAll-` functions in `GHC.Tc.Utils.TcType`) that all do very similar
    things, but vary in the particular form of type variable that they return. To
    make things worse, the names of these functions are often quite misleading.
    Some particularly egregious examples:
    
    * `splitForAllTys` returns `TyCoVar`s, but `splitSomeForAllTys` returns
      `VarBndr`s.
    * `splitSomeForAllTys` returns `VarBndr`s, but `tcSplitSomeForAllTys` returns
      `TyVar`s.
    * `splitForAllTys` returns `TyCoVar`s, but `splitForAllTysInvis` returns
      `InvisTVBinder`s. (This in particular arose in the context of #18939, and
      this finally motivated me to bite the bullet and improve the status quo
      vis-à-vis how we name these functions.)
    
    In an attempt to bring some sanity to how these functions are named, I have
    opted to rename most of these functions en masse to use consistent suffixes
    that describe the particular form of type variable that each function returns.
    In concrete terms, this amounts to:
    
    * Functions that return a `TyVar` now use the suffix `-TyVar`.
      This caused the following functions to be renamed:
      * `splitTyVarForAllTys` -> `splitForAllTyVars`
      * `splitForAllTy_ty_maybe` -> `splitForAllTyVar_maybe`
      * `tcSplitForAllTys` -> `tcSplitForAllTyVars`
      * `tcSplitSomeForAllTys` -> `tcSplitSomeForAllTyVars`
    * Functions that return a `CoVar` now use the suffix `-CoVar`.
      This caused the following functions to be renamed:
      * `splitForAllTy_co_maybe` -> `splitForAllCoVar_maybe`
    * Functions that return a `TyCoVar` now use the suffix `-TyCoVar`.
      This caused the following functions to be renamed:
      * `splitForAllTy` -> `splitForAllTyCoVar`
      * `splitForAllTys` -> `splitForAllTyCoVars`
      * `splitForAllTys'` -> `splitForAllTyCoVars'`
      * `splitForAllTy_maybe` -> `splitForAllTyCoVar_maybe`
    * Functions that return a `VarBndr` now use the suffix corresponding to the
      most relevant type synonym. This caused the following functions to be renamed:
      * `splitForAllVarBndrs` -> `splitForAllTyCoVarBinders`
      * `splitForAllTysInvis` -> `splitForAllInvisTVBinders`
      * `splitForAllTysReq` -> `splitForAllReqTVBinders`
      * `splitSomeForAllTys` -> `splitSomeForAllTyCoVarBndrs`
      * `tcSplitForAllVarBndrs` -> `tcSplitForAllTyVarBinders`
      * `tcSplitForAllTysInvis` -> `tcSplitForAllInvisTVBinders`
      * `tcSplitForAllTysReq` -> `tcSplitForAllReqTVBinders`
      * `tcSplitForAllTy_maybe` -> `tcSplitForAllTyVarBinder_maybe`
    
    Note that I left the following functions alone:
    
    * Functions that split apart things besides `ForAllTy`s, such as `splitFunTys`
      or `splitPiTys`. Thankfully, there are far fewer of these functions than
      there are functions that split apart `ForAllTy`s, so there isn't much of a
      pressing need to apply the new naming convention elsewhere.
    * Functions that split apart `ForAllCo`s in `Coercion`s, such as
      `GHC.Core.Coercion.splitForAllCo_maybe`. We could theoretically apply the new
      naming convention here, but then we'd have to figure out how to disambiguate
      `Type`-splitting functions from `Coercion`-splitting functions. Ultimately,
      the `Coercion`-splitting functions aren't used nearly as much as the
      `Type`-splitting functions, so I decided to leave the former alone.
    
    This is purely refactoring and should cause no change in behavior.
    d61adb3d
Decl.hs 32.8 KB