[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