Skip to content
  • Yiyun Liu's avatar
    35aef18d
    Remove TCvSubst and use Subst for both term and type-level subst · 35aef18d
    Yiyun Liu authored and Marge Bot's avatar Marge Bot committed
    This patch removes the TCvSubst data type and instead uses Subst as
    the environment for both term and type level substitution. This
    change is partially motivated by the existential type proposal,
    which will introduce types that contain expressions and therefore
    forces us to carry around an "IdSubstEnv" even when substituting for
    types. It also reduces the amount of code because "Subst" and
    "TCvSubst" share a lot of common operations. There isn't any
    noticeable impact on performance (geo. mean for ghc/alloc is around
    0.0% but we have -94 loc and one less data type to worry abount).
    
    Currently, the "TCvSubst" data type for substitution on types is
    identical to the "Subst" data type except the former doesn't store
    "IdSubstEnv". Using "Subst" for type-level substitution means there
    will be a redundant field stored in the data type. However, in cases
    where the substitution starts from the expression, using "Subst" for
    type-level substitution saves us from having to project "Subst" into a
    "TCvSubst". This probably explains why the allocation is mostly even
    despite the redundant field.
    
    The patch deletes "TCvSubst" and moves "Subst" and its relevant
    functions from "GHC.Core.Subst" into "GHC.Core.TyCo.Subst".
    Substitution on expressions is still defined in "GHC.Core.Subst" so we
    don't have to expose the definition of "Expr" in the hs-boot file that
    "GHC.Core.TyCo.Subst" must import to refer to "IdSubstEnv" (whose
    codomain is "CoreExpr"). Most functions named fooTCvSubst are renamed
    into fooSubst with a few exceptions (e.g. "isEmptyTCvSubst" is a
    distinct function from "isEmptySubst"; the former ignores the
    emptiness of "IdSubstEnv"). These exceptions mainly exist for
    performance reasons and will go away when "Expr" and "Type" are
    mutually recursively defined (we won't be able to take those
    shortcuts if we can't make the assumption that expressions don't
    appear in types).
    35aef18d
    Remove TCvSubst and use Subst for both term and type-level subst
    Yiyun Liu authored and Marge Bot's avatar Marge Bot committed
    This patch removes the TCvSubst data type and instead uses Subst as
    the environment for both term and type level substitution. This
    change is partially motivated by the existential type proposal,
    which will introduce types that contain expressions and therefore
    forces us to carry around an "IdSubstEnv" even when substituting for
    types. It also reduces the amount of code because "Subst" and
    "TCvSubst" share a lot of common operations. There isn't any
    noticeable impact on performance (geo. mean for ghc/alloc is around
    0.0% but we have -94 loc and one less data type to worry abount).
    
    Currently, the "TCvSubst" data type for substitution on types is
    identical to the "Subst" data type except the former doesn't store
    "IdSubstEnv". Using "Subst" for type-level substitution means there
    will be a redundant field stored in the data type. However, in cases
    where the substitution starts from the expression, using "Subst" for
    type-level substitution saves us from having to project "Subst" into a
    "TCvSubst". This probably explains why the allocation is mostly even
    despite the redundant field.
    
    The patch deletes "TCvSubst" and moves "Subst" and its relevant
    functions from "GHC.Core.Subst" into "GHC.Core.TyCo.Subst".
    Substitution on expressions is still defined in "GHC.Core.Subst" so we
    don't have to expose the definition of "Expr" in the hs-boot file that
    "GHC.Core.TyCo.Subst" must import to refer to "IdSubstEnv" (whose
    codomain is "CoreExpr"). Most functions named fooTCvSubst are renamed
    into fooSubst with a few exceptions (e.g. "isEmptyTCvSubst" is a
    distinct function from "isEmptySubst"; the former ignores the
    emptiness of "IdSubstEnv"). These exceptions mainly exist for
    performance reasons and will go away when "Expr" and "Type" are
    mutually recursively defined (we won't be able to take those
    shortcuts if we can't make the assumption that expressions don't
    appear in types).
Loading