Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adapt to TypeAbstractions in GHC 9.8 #103

Closed
5 tasks done
Tracked by #6746 ...
RyanGlScott opened this issue Jun 9, 2023 · 0 comments · Fixed by #104
Closed
5 tasks done
Tracked by #6746 ...

Adapt to TypeAbstractions in GHC 9.8 #103

RyanGlScott opened this issue Jun 9, 2023 · 0 comments · Fixed by #104

Comments

@RyanGlScott
Copy link
Collaborator

RyanGlScott commented Jun 9, 2023

GHC recently landed !9480, an implementation of GHC proposal #425. This introduces invisible @k-binders for type-level declarations, guarded behind the TypeAbstractions extension. For example:

data D @k @j (a :: k) (b :: j) = ...
       ^^ ^^

This comes with corresponding changes to the Template Haskell AST, as described in the GHC 9.8 Migration Guide:

 data Dec
   = ...
-  | DataD Cxt Name [TyVarBndr ()] (Maybe Kind) [Con] [DerivClause]
-  | NewtypeD Cxt Name [TyVarBndr ()] (Maybe Kind) Con [DerivClause]
-  | TypeDataD Name [TyVarBndr ()] (Maybe Kind) [Con]
-  | TySynD Name [TyVarBndr ()] Type
-  | ClassD Cxt Name [TyVarBndr ()] [FunDep] [Dec]
-  | DataFamilyD Name [TyVarBndr ()] (Maybe Kind)
+  | DataD Cxt Name [TyVarBndr BndrVis] (Maybe Kind) [Con] [DerivClause]
+  | NewtypeD Cxt Name [TyVarBndr BndrVis] (Maybe Kind) Con [DerivClause]
+  | TypeDataD Name [TyVarBndr BndrVis] (Maybe Kind) [Con]
+  | TySynD Name [TyVarBndr BndrVis] Type
+  | ClassD Cxt Name [TyVarBndr BndrVis] [FunDep] [Dec]
+  | DataFamilyD Name [TyVarBndr BndrVis] (Maybe Kind)
   | ...

 data TypeFamilyHead =
-  TypeFamilyHead Name [TyVarBndr ()]      FamilyResultSig (Maybe InjectivityAnn)
+  TypeFamilyHead Name [TyVarBndr BndrVis] FamilyResultSig (Maybe InjectivityAnn)

Where BndrVis is defined as:

data BndrVis = BndrReq   -- a
             | BndrInvis -- @a

As a result of these changes, th-abstraction will need to be updated. I have started working on this in the https://github.com/glguy/th-abstraction/tree/type-abstractions branch, but there is some remaining work to do:

RyanGlScott added a commit that referenced this issue Jul 26, 2023
GHC 9.8 implements
[GHC proposal #425](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst),
which adds support for invisible binders for type-level declarations. This
impacts Template Haskell, as various `TyVarBndr`s are now parameterized by a
new `BndrVis` type instead of `()`.

As such, `th-abstraction` must be updated accordingly. This patch does so by:

* Backporting `BndrVis` to `Language.Haskell.TH.Datatype.TyVarBndr`, as well as
  related types and utility functions. With these changes, one can write
  `BndrVis`-related code that will compile on all GHC versions without CPP.

* Changing `dataDCompat` and `newtypeDCompat` in `Language.Haskell.TH.Datatype`
  to use `TyVarBndrVis` instead of `TyVarBndrUnit` to make it compile on GHC
  9.8, matching similar changes in `DataD` and `NewtypeD` in
  `template-haskell`. Because `BndrVis` is a synonym for `()` on pre-9.8
  versions of GHC, this change is unlikely to break any existing code, but do
  be aware of this change if you write code that needs to support GHC 9.8 or
  later.

See the `th-abstraction` changelog for the full details.

Fixes #103.
RyanGlScott added a commit that referenced this issue Jul 31, 2023
GHC 9.8 implements
[GHC proposal #425](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst),
which adds support for invisible binders for type-level declarations. This
impacts Template Haskell, as various `TyVarBndr`s are now parameterized by a
new `BndrVis` type instead of `()`.

As such, `th-abstraction` must be updated accordingly. This patch does so by:

* Backporting `BndrVis` to `Language.Haskell.TH.Datatype.TyVarBndr`, as well as
  related types and utility functions. With these changes, one can write
  `BndrVis`-related code that will compile on all GHC versions without CPP.

* Changing `dataDCompat` and `newtypeDCompat` in `Language.Haskell.TH.Datatype`
  to use `TyVarBndrVis` instead of `TyVarBndrUnit` to make it compile on GHC
  9.8, matching similar changes in `DataD` and `NewtypeD` in
  `template-haskell`. Because `BndrVis` is a synonym for `()` on pre-9.8
  versions of GHC, this change is unlikely to break any existing code, but do
  be aware of this change if you write code that needs to support GHC 9.8 or
  later.

See the `th-abstraction` changelog for the full details.

Fixes #103.
RyanGlScott added a commit that referenced this issue Jul 31, 2023
GHC 9.8 implements
[GHC proposal #425](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst),
which adds support for invisible binders for type-level declarations. This
impacts Template Haskell, as various `TyVarBndr`s are now parameterized by a
new `BndrVis` type instead of `()`.

As such, `th-abstraction` must be updated accordingly. This patch does so by:

* Backporting `BndrVis` to `Language.Haskell.TH.Datatype.TyVarBndr`, as well as
  related types and utility functions. With these changes, one can write
  `BndrVis`-related code that will compile on all GHC versions without CPP.

* Changing `dataDCompat` and `newtypeDCompat` in `Language.Haskell.TH.Datatype`
  to use `TyVarBndrVis` instead of `TyVarBndrUnit` to make it compile on GHC
  9.8, matching similar changes in `DataD` and `NewtypeD` in
  `template-haskell`. Because `BndrVis` is a synonym for `()` on pre-9.8
  versions of GHC, this change is unlikely to break any existing code, but do
  be aware of this change if you write code that needs to support GHC 9.8 or
  later.

See the `th-abstraction` changelog for the full details.

Fixes #103.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant