[Git][ghc/ghc][wip/soulomoon/suggest-UnliftedNewtypes-unlifted-data-family-25593] update note [Data family/instance return kinds] and [Defaulting result kind of...

Patrick (@soulomoon) gitlab at gitlab.haskell.org
Thu Jan 9 17:38:08 UTC 2025



Patrick pushed to branch wip/soulomoon/suggest-UnliftedNewtypes-unlifted-data-family-25593 at Glasgow Haskell Compiler / GHC


Commits:
8ef3c679 by Patrick at 2025-01-10T01:37:57+08:00
update note [Data family/instance return kinds] and [Defaulting result kind of newtype/data family instance]

- - - - -


2 changed files:

- compiler/GHC/Tc/TyCl.hs
- compiler/GHC/Tc/TyCl/Instance.hs


Changes:

=====================================
compiler/GHC/Tc/TyCl.hs
=====================================
@@ -2218,14 +2218,20 @@ DF0 Where these kinds come from:
      Type. This assumption is in getInitialKind for CUSKs or
      get_fam_decl_initial_kind for non-signature & non-CUSK cases.
 
-   Instances: The data family already has a known kind. The return kind
-     of an instance is then calculated by applying the data family tycon
-     to the patterns provided, as computed by the typeKind lhs_ty in the
-     end of tcDataFamInstHeader. In the case of an instance written in GADT
-     syntax, there are potentially *two* return kinds: the one computed from
-     applying the data family tycon to the patterns, and the one given by
-     the user. This second kind is checked by the tc_kind_sig function within
-     tcDataFamInstHeader. See also DF3, below.
+    Instances: There are potentially *two* return kinds:
+     * Master kind:
+       The data family already has a known kind. The return kind
+       of an instance is then calculated by applying the data family tycon
+       to the patterns provided, as computed by the `tcInstInvisibleTyBinders
+       lhs_ty lhs_kind` in the tcDataFamInstHeader.
+     * Instance kind:
+       The kind specified by the user in GADT syntax. If H98 syntax is used,
+       with UnliftedNewtypes/UnliftedDatatypes, it defaults to newOpenTypeKind
+       for newtypes/datatypes, otherwise it defaults to liftedTypeKind.
+       This is checked or defaulted by the tc_kind_sig function within
+       tcDataFamInstHeader. Defaulting can be tricky since it is guiding
+       instantiation (Note [Defaulting result kind of newtype/data family instance]).
+       See also DF3, below.
 
 DF1 In a data/newtype instance, we treat the kind of the /data family/,
     once instantiated, as the "master kind" for the representation


=====================================
compiler/GHC/Tc/TyCl/Instance.hs
=====================================
@@ -1011,7 +1011,7 @@ tcDataFamInstHeader mb_clsinfo skol_info fam_tc hs_outer_bndrs fixity
 
     -- See Note [Implementation of UnliftedNewtypes] in GHC.Tc.TyCl, families (2),
     -- , Note [Implementation of UnliftedDatatypes]
-    -- and Note [Defaulting kind of newtype/data family instance].
+    -- and Note [Defaulting result kind of newtype/data family instance].
     tc_kind_sig Nothing
       = do { unlifted_newtypes  <- xoptM LangExt.UnliftedNewtypes
            ; unlifted_datatypes <- xoptM LangExt.UnliftedDatatypes
@@ -1037,12 +1037,11 @@ we actually have a place to put the regeneralised variables.
 Thus: skolemise away. cf. GHC.Tc.Utils.Unify.tcTopSkolemise
 Examples in indexed-types/should_compile/T12369
 
-Note [Defaulting kind of newtype/data family instance]
+Note [Defaulting result kind of newtype/data family instance]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 It is tempting to let `tc_kind_sig` just return `newOpenTypeKind`
 even without `-XUnliftedNewtypes`, but we rely on `tc_kind_sig` to
-default the result kind of a newtype instance to `Type` when
-`-XUnliftedNewtypes` is not enabled.
+default the result kind of a newtype instance to `Type`.
 Consider the following example:
 
   -- no UnliftedNewtypes



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/8ef3c67976e6900af54508606e16668314674ef2

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/8ef3c67976e6900af54508606e16668314674ef2
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20250109/f5ea9ea3/attachment-0001.html>


More information about the ghc-commits mailing list