diff options
| author | Simon Peyton Jones <simonpj@microsoft.com> | 2021-05-04 08:45:08 +0100 |
|---|---|---|
| committer | Simon Peyton Jones <simonpj@microsoft.com> | 2021-05-06 23:22:19 +0100 |
| commit | 2aeee2886818fc66cc23a92de2339fc56f5904c3 (patch) | |
| tree | 3b5dae15c959efc50507b6169b715574862bbbb8 /compiler/GHC/Core/Multiplicity.hs | |
| parent | 30f6923a834ccaca30c3622a0a82421fabcab119 (diff) | |
| download | haskell-wip/T18481.tar.gz | |
Allow visible type application for levity-poly data conswip/T18481
This patch was driven by #18481, to allow visible type application
for levity-polymorphic newtypes. As so often, it started simple
but grew:
* Significant refactor: I removed HsConLikeOut from the
client-independent Language.Haskell.Syntax.Expr, and put it where it
belongs, as a new constructor `ConLikeTc` in the GHC-specific extension
data type for expressions, `GHC.Hs.Expr.XXExprGhcTc`.
That changed touched a lot of files in a very superficial way.
* Note [Typechecking data constructors] explains the main payload.
The eta-expansion part is no longer done by the typechecker, but
instead deferred to the desugarer, via `ConLikeTc`
* A little side benefit is that I was able to restore VTA for
data types with a "stupid theta": #19775. Not very important,
but the code in GHC.Tc.Gen.Head.tcInferDataCon is is much, much
more elegant now.
* I had to refactor the levity-polymorphism checking code in
GHC.HsToCore.Expr, see
Note [Checking for levity-polymorphic functions]
Note [Checking levity-polymorphic data constructors]
Diffstat (limited to 'compiler/GHC/Core/Multiplicity.hs')
| -rw-r--r-- | compiler/GHC/Core/Multiplicity.hs | 7 |
1 files changed, 3 insertions, 4 deletions
diff --git a/compiler/GHC/Core/Multiplicity.hs b/compiler/GHC/Core/Multiplicity.hs index 881966f8ff..42dc6c4b8b 100644 --- a/compiler/GHC/Core/Multiplicity.hs +++ b/compiler/GHC/Core/Multiplicity.hs @@ -237,9 +237,7 @@ Types don't match, we should get a type error. But this is legal Haskell 98 code! Bad! Bad! Bad! It could be solved with subtyping, but subtyping doesn't combine well with -polymorphism. - -Instead, we generalise the type of Just, when used as term: +polymorphism. Instead, we generalise the type of Just, when used as term: Just :: forall {p}. a %p-> Just a @@ -254,7 +252,8 @@ We only generalise linear fields this way: fields with multiplicity Many, or other multiplicity expressions are exclusive to -XLinearTypes, hence don't have backward compatibility implications. -The implementation is described in Note [Linear fields generalization]. +The implementation is described in Note [Typechecking data constructors] +in GHC.Tc.Gen.Head. More details in the proposal. -} |