HORIZON HASKELLDocslts/ghc-9.10.xc74966e2026-09-27Search names, modules, packages, or :: a typeCtrl K

GHC 9.10.3 · lts/ghc-9.10.x · c74966e · 2026-09-27

Moduleghc-9.10.3GHC2021

GHC.Tc.Deriv.Functor

The deriving code for the Functor, Foldable, and Traversable classes

  • 1 type
  • 6 values
  • Packageghc-9.10.3
  • Exports7
  • LanguageGHC2021
  • LicenceBSD-3-Clause
  • SourceFunctor.hs
datadata FFoldType a
#

Constructors

  • FT
    • ft_triv :: a

      Does not contain variable

    • ft_var :: a

      The variable itself

    • ft_co_var :: a

      The variable itself, contravariantly

    • ft_fun :: a -> a -> a

      Function type

    • ft_tup :: TyCon -> [a] -> a

      Tuple type. The [a] is the result of folding over the arguments of the tuple.

    • ft_ty_app :: Type -> Type -> a -> a

      Type app, variable only in last argument. The two Types are the function and argument parts of fun_ty arg_ty, respectively.

    • ft_bad_app :: a

      Type app, variable other than in last argument

    • ft_forall :: TcTyVar -> a -> a

      Forall type

valuedeepSubtypesContaining :: TyVar -> Type -> [TcType]
#

Return all syntactic subterms of a Type that are applied to the TyVar argument. This determines what constraints should be inferred for derived Functor, Foldable, and Traversable instances in GHC.Tc.Deriv.Infer. For instance, if we have:

data Foo a = MkFoo Int a (Maybe a) (Either Int (Maybe a))

Then the following would hold:

As used in GHC.Tc.Deriv.Infer, the Type argument will always come from derivDataConInstArgTys, so it is important that the TyVar comes from dataConUnivTyVars to match. Make sure not to take the TyVar from tyConTyVars, as these differ from the dataConUnivTyVars when the data type is a GADT. (See #22167 for what goes wrong if tyConTyVars is used.)