GHC issueshttps://gitlab.haskell.org/ghc/ghc//issues20210705T10:57:13Zhttps://gitlab.haskell.org/ghc/ghc//issues/17183XDerivingVia (and deriving strategies) is under specified in the manual20210705T10:57:13ZRichard Eisenbergrae@richarde.devXDerivingVia (and deriving strategies) is under specified in the manualI had forgotten the syntax for derivingstrategies. Specifically, I wanted to know whether I had to put the strategy *before* or *after* the list of classes. So I looked it up.... but the [manual](https://downloads.haskell.org/~ghc/lates...I had forgotten the syntax for derivingstrategies. Specifically, I wanted to know whether I had to put the strategy *before* or *after* the list of classes. So I looked it up.... but the [manual](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#derivingstrategies) doesn't say. The examples suggest that the strategy comes before, but then in the `XDerivingVia` section, the strategy comes after. Are both allowed? Is `via` allowed prefix? It is a mystery.
And then I looked through the `XDerivingVia` [documentation](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#derivingvia). That is explained entirely by example, with no standalone specification. Yet the specification really has been worked out  it's in the paper. This text should be incorporated into the users' guide, along with a link to the paper (which I also did not see). Also needed are a description of how typing works  or at least scoping. It's very nontrivial.https://gitlab.haskell.org/ghc/ghc//issues/17037Stock deriving improvements20200123T19:42:31ZSophie TaylorStock deriving improvements## Motivation
Trying to use GHCderived code in performancesensitive applications leads to several problems:
1. SPECIALISE pragmas have nothing to inline if the relevant types with GHCderived instances are defined in another file
2. ...## Motivation
Trying to use GHCderived code in performancesensitive applications leads to several problems:
1. SPECIALISE pragmas have nothing to inline if the relevant types with GHCderived instances are defined in another file
2. No class law RULES seem to be generated, either. This is particularly troublesome with DeriveFunctor/DeriveFoldable/DeriveTraversable.
## Proposal
1. GHCderived instances should have INLINABLE pragmas.
2. I'm pretty certain that GHC generates lawabiding instances for Functor/Foldable/Traversable, so the relevant laws should be generated as RULES specific for the types its generating instances for.https://gitlab.haskell.org/ghc/ghc//issues/17013GHC accepts DerivingViagenerated instances that violate functional dependencies20190801T11:47:52ZAlexis KingGHC accepts DerivingViagenerated instances that violate functional dependencies## Summary
Instances generated using `DerivingVia` are accepted even though equivalent handwritten instances are rejected due to violation of the (liberal) coverage condition.
## Steps to reproduce
This module demonstrates the problem...## Summary
Instances generated using `DerivingVia` are accepted even though equivalent handwritten instances are rejected due to violation of the (liberal) coverage condition.
## Steps to reproduce
This module demonstrates the problem:
```haskell
{# LANGUAGE DerivingVia #}
{# LANGUAGE FunctionalDependencies #}
{# LANGUAGE FlexibleInstances #}
module DerivingViaBug where
class C a b  b > a
newtype A t a = A a
instance C t (A t a)
data T = T
deriving (C a) via (A () T)
```
The above program is accepted. But if we write the `C a T` instance manually, rather than deriving it, the program is rejected:
```haskell
data T = T
instance C a T
```
```
src/DerivingViaBug.hs:13:10: error:
• Illegal instance declaration for ‘C a T’
The coverage condition fails in class ‘C’
for functional dependency: ‘b > a’
Reason: lhs type ‘T’ does not determine rhs type ‘a’
Undetermined variable: a
• In the instance declaration for ‘C a T’

13  instance C a T
 ^^^^^
```
## Expected behavior
The simplest solution to this problem would be to reject the derived instance. However, this introduces a bit of an inconsistency between functional dependencies and associated types. Consider the following similar program, which uses associated types instead of functional dependencies:
```haskell
{# LANGUAGE DerivingVia #}
{# LANGUAGE FlexibleInstances #}
{# LANGUAGE TypeFamilies #}
{# LANGUAGE UndecidableInstances #}
module DerivingViaBug where
class C a where
type F a
newtype A t a = A a
instance C (A t a) where
type F (A t a) = t
data T = T
deriving (C) via (A () T)
```
This program is accepted, and the behavior is reasonable. The derived instance is
```haskell
instance C T where
type F T = F (A () T)
```
so `F T` is ultimately `()`. To achieve analogous behavior for functional dependencies, it seems like a reasonable derived instance could be
```haskell
instance C () T
```
which can be constructed by applying the substitution {`t` ↦ `()`, `a` ↦ `T`} to the original `C t (A t a)` instance declaration. I haven’t thought about it enough to say whether or not that would cause more problems than it would solve, however.
## Environment
* GHC version used: 8.6.5
* Operating System: macOS 10.14.5 (18F132)
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc//issues/15969Generic1 deriving should use more coercions20211001T20:51:20ZDavid FeuerGeneric1 deriving should use more coercionsConsider
```hs
newtype Foo a = Foo (Maybe [a]) deriving (Generic1)
```
This produces some rather unsatisfactory Core:
```
 to1 worker
Travv.$fGeneric1Foo1 :: forall a. Rep1 Foo a > Maybe [a]
Travv.$fGeneric1Foo1
= \ (@ a_a7RL) (d...Consider
```hs
newtype Foo a = Foo (Maybe [a]) deriving (Generic1)
```
This produces some rather unsatisfactory Core:
```
 to1 worker
Travv.$fGeneric1Foo1 :: forall a. Rep1 Foo a > Maybe [a]
Travv.$fGeneric1Foo1
= \ (@ a_a7RL) (ds_d9dZ :: Rep1 Foo a_a7RL) >
case ds_d9dZ `cast` <Co:103> of {
Nothing > GHC.Maybe.Nothing @ [a_a7RL];
Just a1_a9fD > GHC.Maybe.Just @ [a_a7RL] (a1_a9fD `cast` <Co:5>)
}
 from1 worker
Travv.$fGeneric1Foo2 :: forall a. Foo a > Maybe (Rec1 [] a)
Travv.$fGeneric1Foo2
= \ (@ a_a7R6) (x_a7GJ :: Foo a_a7R6) >
case x_a7GJ `cast` <Co:2> of {
Nothing > GHC.Maybe.Nothing @ (Rec1 [] a_a7R6);
Just a1_a9fD >
GHC.Maybe.Just @ (Rec1 [] a_a7R6) (a1_a9fD `cast` <Co:6>)
}
```
Both of these functions could be implemented as safe coercions, but neither of them is! Similarly, if I define
```hs
data Bar a = Bar (Maybe [a]) deriving Generic1
```
I get a `to1` worker that looks like
```
Travv.$fGeneric1Bar_$cto1 :: forall a. Rep1 Bar a > Bar a
Travv.$fGeneric1Bar_$cto1
= \ (@ a_a7UA) (ds_d9ho :: Rep1 Bar a_a7UA) >
Travv.Bar
@ a_a7UA
(case ds_d9ho `cast` <Co:103> of {
Nothing > GHC.Maybe.Nothing @ [a_a7UA];
Just a1_a9iK > GHC.Maybe.Just @ [a_a7UA] (a1_a9iK `cast` <Co:5>)
})
```
That `case` expression should really just be a cast.
I think the basic trick is probably to inspect the role of the type argument of each type in a composition, using that to work out whether to coerce that step.
<details><summary>Trac metadata</summary>
 Trac field  Value 
    
 Version  8.6.2 
 Type  Bug 
 TypeOfFailure  OtherFailure 
 Priority  normal 
 Resolution  Unresolved 
 Component  Compiler 
 Test case  
 Differential revisions  
 BlockedBy  
 Related  
 Blocking  
 CC  RyanGlScott 
 Operating system  
 Architecture  
</details>
<! {"blocked_by":[],"summary":"Generic1 deriving should use more coercions","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":["Generics"],"differentials":[],"test_case":"","architecture":"","cc":["RyanGlScott"],"type":"Bug","description":"Consider\r\n\r\n{{{#!hs\r\nnewtype Foo a = Foo (Maybe [a]) deriving (Generic1)\r\n}}}\r\n\r\nThis produces some rather unsatisfactory Core:\r\n\r\n{{{\r\n to1 worker\r\nTravv.$fGeneric1Foo1 :: forall a. Rep1 Foo a > Maybe [a]\r\nTravv.$fGeneric1Foo1\r\n = \\ (@ a_a7RL) (ds_d9dZ :: Rep1 Foo a_a7RL) >\r\n case ds_d9dZ `cast` <Co:103> of {\r\n Nothing > GHC.Maybe.Nothing @ [a_a7RL];\r\n Just a1_a9fD > GHC.Maybe.Just @ [a_a7RL] (a1_a9fD `cast` <Co:5>)\r\n}\r\n\r\n from1 worker\r\nTravv.$fGeneric1Foo2 :: forall a. Foo a > Maybe (Rec1 [] a)\r\nTravv.$fGeneric1Foo2\r\n = \\ (@ a_a7R6) (x_a7GJ :: Foo a_a7R6) >\r\n case x_a7GJ `cast` <Co:2> of {\r\n Nothing > GHC.Maybe.Nothing @ (Rec1 [] a_a7R6);\r\n Just a1_a9fD >\r\n GHC.Maybe.Just @ (Rec1 [] a_a7R6) (a1_a9fD `cast` <Co:6>)\r\n }\r\n}}}\r\n\r\nBoth of these functions could be implemented as safe coercions, but neither of them is! Similarly, if I define\r\n\r\n{{{#!hs\r\ndata Bar a = Bar (Maybe [a]) deriving Generic1\r\n}}}\r\n\r\nI get a `to1` worker that looks like\r\n\r\n{{{\r\nTravv.$fGeneric1Bar_$cto1 :: forall a. Rep1 Bar a > Bar a\r\nTravv.$fGeneric1Bar_$cto1\r\n = \\ (@ a_a7UA) (ds_d9ho :: Rep1 Bar a_a7UA) >\r\n Travv.Bar\r\n @ a_a7UA\r\n (case ds_d9ho `cast` <Co:103> of {\r\n Nothing > GHC.Maybe.Nothing @ [a_a7UA];\r\n Just a1_a9iK > GHC.Maybe.Just @ [a_a7UA] (a1_a9iK `cast` <Co:5>)\r\n })\r\n}}}\r\n\r\nThat `case` expression should really just be a cast.\r\n\r\nI think the basic trick is probably to inspect the role of the type argument of each type in a composition, using that to work out whether to coerce that step.","type_of_failure":"OtherFailure","blocking":[]} >https://gitlab.haskell.org/ghc/ghc//issues/15868Standard deriving should be less conservative when `UndecidableInstances` is ...20190722T17:04:42Zedsko@edsko.netStandard deriving should be less conservative when `UndecidableInstances` is enabledThe following program
```hs
{# LANGUAGE FlexibleContexts #}
{# LANGUAGE FlexibleInstances #}
{# LANGUAGE StandaloneDeriving #}
{# LANGUAGE TypeFamilies #}
{# LANGUAGE UndecidableInstances #}
module Exp where
...The following program
```hs
{# LANGUAGE FlexibleContexts #}
{# LANGUAGE FlexibleInstances #}
{# LANGUAGE StandaloneDeriving #}
{# LANGUAGE TypeFamilies #}
{# LANGUAGE UndecidableInstances #}
module Exp where
type family F a
data T a = MkT (F a)
deriving instance Eq (F a) => Eq (T a)
data T2 a = T2 (T a)
deriving (Eq)
```
results in a type error
```
• No instance for (Eq (F a))
arising from the first field of ‘T2’ (type ‘T a’)
```
According the manual this is expected behaviour (https://downloads.haskell.org/\~ghc/latest/docs/html/users_guide/glasgow_exts.html\#inferredcontextforderivingclauses), but it is unfortunate; it seems to me that there is no deep reason that this instance should be rejected, other than an overly conservative check in the deriving machinery; I propose that this check is relaxed when the `UndecidableInstances` extension is enabled. Mind that I'm *not* proposing that it should also be able to infer the right constraints for `T` itself; but once I write such an explicit context myself once (for `T`), it seems to me that deriving the *same* constraints also for `T2` should be easy.
Note that right now we can workaround this problem using
```hs
class Eq (F a) => EqF a
deriving instance EqF a => Eq (T a)
data T2 a = T2 (T a)
deriving (Eq)
```
Normally however for such a class synonym we would then provide a single "authoritative" instance:
```hs
class Eq (F a) => EqF a
instance Eq (F a) => EqF a
```
but if we do that then we are back at the same error for `T2`, because ghc will go from the `EqF a` constraint to the `Eq (F a)` constraint, and then refuse to add that constraint.
<details><summary>Trac metadata</summary>
 Trac field  Value 
    
 Version  8.6.1 
 Type  FeatureRequest 
 TypeOfFailure  OtherFailure 
 Priority  normal 
 Resolution  Unresolved 
 Component  Compiler 
 Test case  
 Differential revisions  
 BlockedBy  
 Related  
 Blocking  
 CC  
 Operating system  
 Architecture  
</details>
<! {"blocked_by":[],"summary":"Standard deriving should be less conservative when `UndecidableInstances` is enabled","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"The following program\r\n\r\n{{{#!hs\r\n{# LANGUAGE FlexibleContexts #}\r\n{# LANGUAGE FlexibleInstances #}\r\n{# LANGUAGE StandaloneDeriving #}\r\n{# LANGUAGE TypeFamilies #}\r\n{# LANGUAGE UndecidableInstances #}\r\n\r\nmodule Exp where\r\n\r\ntype family F a\r\n\r\ndata T a = MkT (F a)\r\n\r\nderiving instance Eq (F a) => Eq (T a)\r\n\r\ndata T2 a = T2 (T a)\r\n deriving (Eq)\r\n}}}\r\n\r\nresults in a type error\r\n\r\n{{{\r\n • No instance for (Eq (F a))\r\n arising from the first field of ‘T2’ (type ‘T a’)\r\n}}}\r\n\r\nAccording the manual this is expected behaviour (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#inferredcontextforderivingclauses), but it is unfortunate; it seems to me that there is no deep reason that this instance should be rejected, other than an overly conservative check in the deriving machinery; I propose that this check is relaxed when the `UndecidableInstances` extension is enabled. Mind that I'm ''not'' proposing that it should also be able to infer the right constraints for `T` itself; but once I write such an explicit context myself once (for `T`), it seems to me that deriving the ''same'' constraints also for `T2` should be easy.\r\n\r\nNote that right now we can workaround this problem using\r\n\r\n{{{#!hs\r\nclass Eq (F a) => EqF a\r\n\r\nderiving instance EqF a => Eq (T a)\r\n\r\ndata T2 a = T2 (T a)\r\n deriving (Eq)\r\n}}}\r\n\r\nNormally however for such a class synonym we would then provide a single \"authoritative\" instance:\r\n\r\n{{{#!hs\r\nclass Eq (F a) => EqF a\r\ninstance Eq (F a) => EqF a\r\n}}}\r\n\r\nbut if we do that then we are back at the same error for `T2`, because ghc will go from the `EqF a` constraint to the `Eq (F a)` constraint, and then refuse to add that constraint. ","type_of_failure":"OtherFailure","blocking":[]} >https://gitlab.haskell.org/ghc/ghc//issues/15650Add (or document if already exist) ability to derive custom typeclasses via s...20210914T15:15:42ZDmitrii KovanikovAdd (or document if already exist) ability to derive custom typeclasses via source plugins## Problem
Suppose, I have some custom typeclass `Foo` defined in some library `foo`:
```hs
class Foo a where
... some methods ...
```
I would like to be able to derive instances of this typeclass for any possible data type using ...## Problem
Suppose, I have some custom typeclass `Foo` defined in some library `foo`:
```hs
class Foo a where
... some methods ...
```
I would like to be able to derive instances of this typeclass for any possible data type using `deriving` clause just like GHC already does for typeclasses `Eq`, `Ord`, `Show`, `Read`, `Enum`, etc.:
```hs
data Bar = Bar  Baz
deriving (Eq, Ord, Foo)
```
There're already two possible ways to derive instances of custom typeclasses:
1. `anyclass` deriving strategy (usually involves `Generic`)
1. `XTemplateHaskell` solution.
But I would like to have sourcepluginbased solution for this problem so I can just add `fplugin=Foo.Plugin` and enjoy deriving capabilities.
## Advantage over existing approaches
Solution with `XTemplateHaskell` is not that pleasant to write and easy to maintain (you need to use libraries like http://hackage.haskell.org/package/thabstraction to support multiple GHC versions),involves scoping restriction and is syntactically uglier. Compare:
```hs
{# LANGUAGE TemplateHaskell #}
data Bar = Bar  Baz
deriving (Eq, Ord)
deriveFoo ''Bar
```
Solution with something like `Generic` introduces performance overhead (required for to/from generic representation conversion). This might not be significant for something like *parsing CLI arguments* but it's more important if you want to have efficient binary serialisation.
Also, it's known that deriving typeclasses is a relatively slow compilation process (https://github.com/tfausak/tfausak.github.io/issues/127) so there's slight chance that deriving typeclass manually can be slightly faster than deriving `Generic + MyClass`. Especially when maintainers of plugins can experiment with some caching strategies for deriving typeclasses.
<details><summary>Trac metadata</summary>
 Trac field  Value 
    
 Version  8.6.1beta1 
 Type  FeatureRequest 
 TypeOfFailure  OtherFailure 
 Priority  normal 
 Resolution  Unresolved 
 Component  Compiler 
 Test case  
 Differential revisions  
 BlockedBy  
 Related  
 Blocking  
 CC  
 Operating system  
 Architecture  
</details>
<! {"blocked_by":[],"summary":"Add (or document if already exist) ability to derive custom typeclasses via source plugins","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1beta1","keywords":["plugins,deriving,typeclass","source"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"== Problem\r\n\r\nSuppose, I have some custom typeclass `Foo` defined in some library `foo`:\r\n\r\n{{{#!hs\r\nclass Foo a where\r\n ... some methods ...\r\n}}}\r\n\r\nI would like to be able to derive instances of this typeclass for any possible data type using `deriving` clause just like GHC already does for typeclasses `Eq`, `Ord`, `Show`, `Read`, `Enum`, etc.:\r\n\r\n{{{#!hs\r\ndata Bar = Bar  Baz\r\n deriving (Eq, Ord, Foo)\r\n}}}\r\n\r\nThere're already two possible ways to derive instances of custom typeclasses:\r\n\r\n1. `anyclass` deriving strategy (usually involves `Generic`)\r\n2. `XTemplateHaskell` solution.\r\n\r\nBut I would like to have sourcepluginbased solution for this problem so I can just add `fplugin=Foo.Plugin` and enjoy deriving capabilities.\r\n\r\n== Advantage over existing approaches\r\n\r\nSolution with `XTemplateHaskell` is not that pleasant to write and easy to maintain (you need to use libraries like http://hackage.haskell.org/package/thabstraction to support multiple GHC versions),involves scoping restriction and is syntactically uglier. Compare:\r\n\r\n{{{#!hs\r\n{# LANGUAGE TemplateHaskell #}\r\n\r\ndata Bar = Bar  Baz\r\n deriving (Eq, Ord)\r\n\r\nderiveFoo ''Bar\r\n}}}\r\n\r\nSolution with something like `Generic` introduces performance overhead (required for to/from generic representation conversion). This might not be significant for something like ''parsing CLI arguments'' but it's more important if you want to have efficient binary serialisation. \r\n\r\nAlso, it's known that deriving typeclasses is a relatively slow compilation process (https://github.com/tfausak/tfausak.github.io/issues/127) so there's slight chance that deriving typeclass manually can be slightly faster than deriving `Generic + MyClass`. Especially when maintainers of plugins can experiment with some caching strategies for deriving typeclasses.","type_of_failure":"OtherFailure","blocking":[]} >8.6.1https://gitlab.haskell.org/ghc/ghc//issues/15434DerivingVia (and perhaps even GND) works badly with DeriveGeneric20210907T15:18:06ZHiromi IshiiDerivingVia (and perhaps even GND) works badly with DeriveGeneric`DerivingVia` together with `DeriveGeneric` can generate wrong instances for `Generic`.
Consider the following:
```haskell
{# LANGUAGE DeriveGeneric, DerivingStrategies, DerivingVia, GADTs #}
{# LANGUAGE GeneralizedNewtypeD...`DerivingVia` together with `DeriveGeneric` can generate wrong instances for `Generic`.
Consider the following:
```haskell
{# LANGUAGE DeriveGeneric, DerivingStrategies, DerivingVia, GADTs #}
{# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies, UndecidableInstances #}
module Data.Foldable.Bad where
import GHC.Generics
newtype Bad a = Bad a deriving (Generic)
data Foo = Foo Int
deriving (Read, Show, Eq, Ord)
deriving (Generic) via Bad Foo
```
which gives the following representation, which is considered to be wrong for `Foo`:
```haskell
ghci> from $ Foo 12
M1 {unM1 = M1 {unM1 = M1 {unM1 = K1 {unK1 = Foo 12}}}}
ghci> :t it
it
:: D1
('MetaData "Bad" "Data.Foldable.Bad" "main" 'True)
(C1
('MetaCons "Bad" 'PrefixI 'False)
(S1
('MetaSel
'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy)
(Rec0 Foo)))
x
```
Also, `DerivingStrategies` + GND + `DeriveGeneric` already can generate wrong instance:
```haskell
newtype Bad2 = Bad2 Bool
deriving newtype (Generic)
{
ghci> from $ Bad2 False
M1 {unM1 = L1 (M1 {unM1 = U1})}
ghci> :t it
it
:: D1
('MetaData "Bool" "GHC.Types" "ghcprim" 'False)
(C1 ('MetaCons "False" 'PrefixI 'False) U1
:+: C1 ('MetaCons "True" 'PrefixI 'False) U1)
x
}
```
I tested this against GHC 8.6.1alpha1.
<details><summary>Trac metadata</summary>
 Trac field  Value 
    
 Version  
 Type  Bug 
 TypeOfFailure  OtherFailure 
 Priority  normal 
 Resolution  Unresolved 
 Component  Compiler 
 Test case  
 Differential revisions  
 BlockedBy  
 Related  
 Blocking  
 CC  
 Operating system  
 Architecture  
</details>
<! {"blocked_by":[],"summary":"DerivingVia (and perhaps even GND) works badly with DeriveGeneric","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`DerivingVia` together with `DeriveGeneric` can generate wrong instances for `Generic`.\r\n\r\nConsider the following:\r\n\r\n{{{#!haskell\r\n{# LANGUAGE DeriveGeneric, DerivingStrategies, DerivingVia, GADTs #}\r\n{# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies, UndecidableInstances #}\r\nmodule Data.Foldable.Bad where\r\nimport GHC.Generics\r\n\r\nnewtype Bad a = Bad a deriving (Generic)\r\ndata Foo = Foo Int\r\n deriving (Read, Show, Eq, Ord)\r\n deriving (Generic) via Bad Foo\r\n}}}\r\n\r\nwhich gives the following representation, which is considered to be wrong for `Foo`:\r\n\r\n{{{#!haskell\r\nghci> from $ Foo 12\r\nM1 {unM1 = M1 {unM1 = M1 {unM1 = K1 {unK1 = Foo 12}}}}\r\nghci> :t it\r\nit\r\n :: D1\r\n ('MetaData \"Bad\" \"Data.Foldable.Bad\" \"main\" 'True)\r\n (C1\r\n ('MetaCons \"Bad\" 'PrefixI 'False)\r\n (S1\r\n ('MetaSel\r\n 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy)\r\n (Rec0 Foo)))\r\n x\r\n}}}\r\n\r\nAlso, `DerivingStrategies` + GND + `DeriveGeneric` already can generate wrong instance:\r\n\r\n{{{#!haskell\r\nnewtype Bad2 = Bad2 Bool\r\n deriving newtype (Generic)\r\n\r\n{\r\n\r\nghci> from $ Bad2 False\r\nM1 {unM1 = L1 (M1 {unM1 = U1})}\r\nghci> :t it\r\nit\r\n :: D1\r\n ('MetaData \"Bool\" \"GHC.Types\" \"ghcprim\" 'False)\r\n (C1 ('MetaCons \"False\" 'PrefixI 'False) U1\r\n :+: C1 ('MetaCons \"True\" 'PrefixI 'False) U1)\r\n x\r\n}\r\n\r\n}}}\r\n\r\nI tested this against GHC 8.6.1alpha1.","type_of_failure":"OtherFailure","blocking":[]} >9.4.1https://gitlab.haskell.org/ghc/ghc//issues/15376GHC determine illegal kind for standalone deriving with Deriving via20210907T15:04:54Zmizunashi_manaGHC determine illegal kind for standalone deriving with Deriving viaHappy to release GHC 8.6.1alpha1! I used it to test new extensions, and then I met below errors:
```
$ ghci8.6.0.20180627
GHCi, version 8.6.0.20180627: http://www.haskell.org/ghc/ :? for help
Prelude> :set XDerivingVia XStandaloneD...Happy to release GHC 8.6.1alpha1! I used it to test new extensions, and then I met below errors:
```
$ ghci8.6.0.20180627
GHCi, version 8.6.0.20180627: http://www.haskell.org/ghc/ :? for help
Prelude> :set XDerivingVia XStandaloneDeriving
Prelude> newtype FunctorWrapped f a = FunctorWrapped (f a)
Prelude> deriving via f instance Functor f => Functor (FunctorWrapped f)
<interactive>:3:33: error:
• Expected kind ‘* > *’, but ‘f’ has kind ‘*’
• In the first argument of ‘Functor’, namely ‘f’
In the standalone deriving instance for
‘Functor f => Functor (FunctorWrapped f)’
<interactive>:3:62: error:
• Expected kind ‘* > *’, but ‘f’ has kind ‘*’
• In the first argument of ‘FunctorWrapped’, namely ‘f’
In the first argument of ‘Functor’, namely ‘(FunctorWrapped f)’
In the standalone deriving instance for
‘Functor f => Functor (FunctorWrapped f)’
```
However,
```
newtype FunctorWrapped f a = FunctorWrapped (f a)
deriving Functor via f
```
is passed through on GHC 8.6.1alpha1.
Is this a bug or my misunderstand?
<details><summary>Trac metadata</summary>
 Trac field  Value 
    
 Version  
 Type  Bug 
 TypeOfFailure  OtherFailure 
 Priority  normal 
 Resolution  Unresolved 
 Component  Compiler 
 Test case  
 Differential revisions  
 BlockedBy  
 Related  
 Blocking  
 CC  
 Operating system  
 Architecture  
</details>
<! {"blocked_by":[],"summary":"GHC determine illegal kind for standalone deriving with Deriving via","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Happy to release GHC 8.6.1alpha1! I used it to test new extensions, and then I met below errors:\r\n\r\n{{{\r\n$ ghci8.6.0.20180627\r\nGHCi, version 8.6.0.20180627: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :set XDerivingVia XStandaloneDeriving\r\nPrelude> newtype FunctorWrapped f a = FunctorWrapped (f a)\r\nPrelude> deriving via f instance Functor f => Functor (FunctorWrapped f)\r\n\r\n<interactive>:3:33: error:\r\n • Expected kind ‘* > *’, but ‘f’ has kind ‘*’\r\n • In the first argument of ‘Functor’, namely ‘f’\r\n In the standalone deriving instance for\r\n ‘Functor f => Functor (FunctorWrapped f)’\r\n\r\n<interactive>:3:62: error:\r\n • Expected kind ‘* > *’, but ‘f’ has kind ‘*’\r\n • In the first argument of ‘FunctorWrapped’, namely ‘f’\r\n In the first argument of ‘Functor’, namely ‘(FunctorWrapped f)’\r\n In the standalone deriving instance for\r\n ‘Functor f => Functor (FunctorWrapped f)’\r\n}}}\r\n\r\nHowever,\r\n\r\n{{{\r\nnewtype FunctorWrapped f a = FunctorWrapped (f a)\r\n deriving Functor via f\r\n}}}\r\n\r\nis passed through on GHC 8.6.1alpha1.\r\n\r\nIs this a bug or my misunderstand?","type_of_failure":"OtherFailure","blocking":[]} >https://gitlab.haskell.org/ghc/ghc//issues/15151Better Interaction Between Specialization and GND20190707T18:14:02ZAndrew MartinBetter Interaction Between Specialization and GNDLet us consider the following code:
```
 Sort.hs
sort :: (Prim a, Ord a) => MutablePrimArray s a > ST s ()
sort mutArr = ...
{# SPECIALIZE sort :: MutablePrimArray s Int > ST s () #}
{# SPECIALIZE sort :: MutablePrimArray s Int8 ...Let us consider the following code:
```
 Sort.hs
sort :: (Prim a, Ord a) => MutablePrimArray s a > ST s ()
sort mutArr = ...
{# SPECIALIZE sort :: MutablePrimArray s Int > ST s () #}
{# SPECIALIZE sort :: MutablePrimArray s Int8 > ST s () #}
{# SPECIALIZE sort :: MutablePrimArray s Word8 > ST s () #}
...
```
For reference, a `MutablePrimArray` is a `MutableByteArray` with a phantom type variable to tag the element type. This sorting algorithm may be implemented in any number of ways, and the implementation is unimportant here. The specialize pragmas are intended to capture a number of common use cases. Here's where a problem arises:
```
 Example.hs
newtype PersonId = PersonId Int
deriving (Eq,Ord,Prim)
sortPeople :: MutablePrimArray s PersonId > MutablePrimArray s PersonId
sortPeople x = sort x
```
There isn't a rewrite rule that specializes the `sort` function when we are dealing with `PersonId`. So, we end up with a slower version of the code that explicitly passes all the dictionaries. One solution would be to just use `INLINABLE` instead. Then we don't have to try to list every type, and we just let the specialization be generate at the call site. But this isn't totally satisfying. There are a lot of types that are just newtype wrappers around `Int`. Why should we have an extra copy of the same code for each of them? (Even without newtypes, `INLINABLE` can still result in duplication if neither of the modules that needs a specialization transitively imports the other).
What I'm suggesting is that rewrite rules (like those generated by `SPECIALIZE`) could target not just the given type but also any newtype around it, provided that all typeclass instances required by the function were the result of GND. The only situations where this is unsound are situations where the user was already doing something unsound with rewrite rules. There are several implementation difficulties:
 In core, there is no good way to tell that a typeclass instance dictionary was the result of GND. I'm not sure how to work around this.
 `Eq` and `Ord` usually aren't handled by the `newtype` deriving strategy. They are handled by the `stock` strategy, which produces code with equivalent behavior but is nevertheless different code.
 The rewrite rule would need to look at additional arguments beyond the type arguments.
I suspect that these difficulties would make such this feature difficult to implement, but this feature would help me with some of my libraries and applications.
<details><summary>Trac metadata</summary>
 Trac field  Value 
    
 Version  8.4.2 
 Type  FeatureRequest 
 TypeOfFailure  OtherFailure 
 Priority  normal 
 Resolution  Unresolved 
 Component  Compiler 
 Test case  
 Differential revisions  
 BlockedBy  
 Related  
 Blocking  
 CC  
 Operating system  
 Architecture  
</details>
<! {"blocked_by":[],"summary":"Better Interaction Specialization and GND","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Let us consider the following code:\r\n\r\n{{{\r\n Sort.hs\r\nsort :: (Prim a, Ord a) => MutablePrimArray s a > ST s ()\r\nsort mutArr = ...\r\n{# SPECIALIZE sort :: MutablePrimArray s Int > ST s () #}\r\n{# SPECIALIZE sort :: MutablePrimArray s Int8 > ST s () #}\r\n{# SPECIALIZE sort :: MutablePrimArray s Word8 > ST s () #}\r\n...\r\n}}}\r\n\r\nFor reference, a `MutablePrimArray` is a `MutableByteArray` with a phantom type variable to tag the element type. This sorting algorithm may be implemented in any number of ways, and the implementation is unimportant here. The specialize pragmas are intended to capture a number of common use cases. Here's where a problem arises:\r\n\r\n{{{\r\n Example.hs\r\nnewtype PersonId = PersonId Int\r\n deriving (Eq,Ord,Prim)\r\nsortPeople :: MutablePrimArray s PersonId > MutablePrimArray s PersonId\r\nsortPeople x = sort x\r\n}}}\r\n\r\nThere isn't a rewrite rule that specializes the `sort` function when we are dealing with `PersonId`. So, we end up with a slower version of the code that explicitly passes all the dictionaries. One solution would be to just use `INLINABLE` instead. Then we don't have to try to list every type, and we just let the specialization be generate at the call site. But this isn't totally satisfying. There are a lot of types that are just newtype wrappers around `Int`. Why should we have an extra copy of the same code for each of them? (Even without newtypes, `INLINABLE` can still result in duplication if neither of the modules that needs a specialization transitively imports the other).\r\n\r\nWhat I'm suggesting is that rewrite rules (like those generated by `SPECIALIZE`) could target not just the given type but also any newtype around it, provided that all typeclass instances required by the function were the result of GND. The only situations where this is unsound are situations where the user was already doing something unsound with rewrite rules. There are several implementation difficulties:\r\n\r\n* In core, there is no good way to tell that a typeclass instance dictionary was the result of GND. I'm not sure how to work around this.\r\n* `Eq` and `Ord` usually aren't handled by the `newtype` deriving strategy. They are handled by the `stock` strategy, which produces code with equivalent behavior but is nevertheless different code.\r\n* The rewrite rule would need to look at additional arguments beyond the type arguments.\r\n\r\nI suspect that these difficulties would make such this feature difficult to implement, but this feature would help me with some of my libraries and applications.","type_of_failure":"OtherFailure","blocking":[]} >Research neededhttps://gitlab.haskell.org/ghc/ghc//issues/14331Overzealous freefloating kind check causes deriving clause to be rejected20200123T19:27:39ZRyan ScottOverzealous freefloating kind check causes deriving clause to be rejectedGHC rejects this program:
```hs
{# LANGUAGE DeriveAnyClass #}
{# LANGUAGE MultiParamTypeClasses #}
{# LANGUAGE PolyKinds #}
module Bug where
class C a b
data D = D deriving (C (a :: k))
```
```
GHCi, version 8.2.1: http://www.h...GHC rejects this program:
```hs
{# LANGUAGE DeriveAnyClass #}
{# LANGUAGE MultiParamTypeClasses #}
{# LANGUAGE PolyKinds #}
module Bug where
class C a b
data D = D deriving (C (a :: k))
```
```
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:8:1: error:
Kind variable ‘k’ is implicitly bound in datatype
‘D’, but does not appear as the kind of any
of its type variables. Perhaps you meant
to bind it (with TypeInType) explicitly somewhere?

8  data D = D deriving (C (a :: k))
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
But it really shouldn't, since it's quite possible to write the code that is should generate:
```hs
instance C (a :: k) D
```
Curiously, this does not appear to happen for data family instances, as this typechecks:
```hs
{# LANGUAGE DeriveAnyClass #}
{# LANGUAGE MultiParamTypeClasses #}
{# LANGUAGE PolyKinds #}
{# LANGUAGE TypeFamilies #}
module Bug where
class C a b
data family D1
data instance D1 = D1 deriving (C (a :: k))
class E where
data D2
instance E where
data D2 = D2 deriving (C (a :: k))
```
<details><summary>Trac metadata</summary>
 Trac field  Value 
    
 Version  8.2.1 
 Type  Bug 
 TypeOfFailure  OtherFailure 
 Priority  normal 
 Resolution  Unresolved 
 Component  Compiler (Type checker) 
 Test case  
 Differential revisions  
 BlockedBy  
 Related  
 Blocking  
 CC  
 Operating system  
 Architecture  
</details>
<! {"blocked_by":[],"summary":"Overzealous freefloating kind check causes deriving clause to be rejected","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["deriving"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC rejects this program:\r\n\r\n{{{#!hs\r\n{# LANGUAGE DeriveAnyClass #}\r\n{# LANGUAGE MultiParamTypeClasses #}\r\n{# LANGUAGE PolyKinds #}\r\nmodule Bug where\r\n\r\nclass C a b\r\n\r\ndata D = D deriving (C (a :: k))\r\n}}}\r\n\r\n{{{\r\nGHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\n\r\nBug.hs:8:1: error:\r\n Kind variable ‘k’ is implicitly bound in datatype\r\n ‘D’, but does not appear as the kind of any\r\n of its type variables. Perhaps you meant\r\n to bind it (with TypeInType) explicitly somewhere?\r\n \r\n8  data D = D deriving (C (a :: k))\r\n  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r\n}}}\r\n\r\nBut it really shouldn't, since it's quite possible to write the code that is should generate:\r\n\r\n{{{#!hs\r\ninstance C (a :: k) D\r\n}}}\r\n\r\nCuriously, this does not appear to happen for data family instances, as this typechecks:\r\n\r\n{{{#!hs\r\n{# LANGUAGE DeriveAnyClass #}\r\n{# LANGUAGE MultiParamTypeClasses #}\r\n{# LANGUAGE PolyKinds #}\r\n{# LANGUAGE TypeFamilies #}\r\nmodule Bug where\r\n\r\nclass C a b\r\n\r\ndata family D1\r\ndata instance D1 = D1 deriving (C (a :: k))\r\n\r\nclass E where\r\n data D2\r\n\r\ninstance E where\r\n data D2 = D2 deriving (C (a :: k))\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} >https://gitlab.haskell.org/ghc/ghc//issues/14030Implement the "Derive Lift instances for data types in templatehaskell" prop...20200123T19:31:02ZRyan ScottImplement the "Derive Lift instances for data types in templatehaskell" proposalBack in September 2015, I [proposed](https://mail.haskell.org/pipermail/libraries/2015September/026117.html) using the `DeriveLift` extension to, well, derive `Lift` instance for data types in the `templatehaskell` library. The proposa...Back in September 2015, I [proposed](https://mail.haskell.org/pipermail/libraries/2015September/026117.html) using the `DeriveLift` extension to, well, derive `Lift` instance for data types in the `templatehaskell` library. The proposal was well received, but I was unable to implement it at the time due to `DeriveLift`'s newness (having only been introduced in GHC 8.0). Now that GHC 8.0 is the oldest version of GHC that we support bootstrapping with, this is no longer an obstacle.
<details><summary>Trac metadata</summary>
 Trac field  Value 
    
 Version  8.3 
 Type  Task 
 TypeOfFailure  OtherFailure 
 Priority  normal 
 Resolution  Unresolved 
 Component  Template Haskell 
 Test case  
 Differential revisions  
 BlockedBy  
 Related  
 Blocking  
 CC  
 Operating system  
 Architecture  
</details>
<! {"blocked_by":[],"summary":"Implement the \"Derive Lift instances for data types in templatehaskell\" proposal","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Back in September 2015, I [https://mail.haskell.org/pipermail/libraries/2015September/026117.html proposed] using the `DeriveLift` extension to, well, derive `Lift` instance for data types in the `templatehaskell` library. The proposal was well received, but I was unable to implement it at the time due to `DeriveLift`'s newness (having only been introduced in GHC 8.0). Now that GHC 8.0 is the oldest version of GHC that we support bootstrapping with, this is no longer an obstacle.","type_of_failure":"OtherFailure","blocking":[]} >https://gitlab.haskell.org/ghc/ghc//issues/13957Allow deriving multiparameter type classes with representationally equal argu...20190707T18:19:11ZIcelandjackAllow deriving multiparameter type classes with representationally equal argumentsThis currently works
```hs
{# Language DerivingStrategies, MultiParamTypeClasses, FunctionalDependencies, GeneralizedNewtypeDeriving #}
import Data.Kind
import Data.Functor.Identity
class SIEVE f p  p > f where
sIEVE :: p a b >...This currently works
```hs
{# Language DerivingStrategies, MultiParamTypeClasses, FunctionalDependencies, GeneralizedNewtypeDeriving #}
import Data.Kind
import Data.Functor.Identity
class SIEVE f p  p > f where
sIEVE :: p a b > a > f b
instance SIEVE Identity (>) where
sIEVE = (Identity .)
newtype ARR a b = ARR (a > b)
deriving newtype
(SIEVE Identity)
```
But what if I want a `Sieve I ARR` instance, for `newtype I a = I a` (which is representationally equal to `newtype Identity a = Identity a`)?
```hs
{# Language DerivingStrategies, MultiParamTypeClasses, FunctionalDependencies, GeneralizedNewtypeDeriving, RankNTypes, TypeApplications, ScopedTypeVariables, InstanceSigs #}
import Data.Kind
import Data.Functor.Identity
import Data.Coerce
class SIEVE f p  p > f where
sIEVE :: p a b > a > f b
instance SIEVE Identity (>) where
sIEVE = (Identity .)
newtype ARR a b = ARR (a > b)
deriving newtype
(SIEVE I)
newtype I a = I a
```
generating the following code (this is basically to code generated before, except replacing some `Identity`s with `I`s
```hs
instance SIEVE I ARR where
sIEVE :: forall a b. ARR a b > (a > I b)
sIEVE
= coerce
@((a > b) > a > Identity b)
@(ARR a b > a > I b)
sIEVE
```
GHC should be able to recover `Identity` due to the functional dependency.https://gitlab.haskell.org/ghc/ghc//issues/13748Variables prettyprinted from ddumpderiv are not scoped properly20190707T18:20:17ZRyan ScottVariables prettyprinted from ddumpderiv are not scoped properlyThis bug is present on GHC 8.0.1, 8.0.2, 8.2.1 and HEAD, and originally noted in #13738\##13748. Take this code:
```hs
{# LANGUAGE GeneralizedNewtypeDeriving #}
{# LANGUAGE PolyKinds #}
{# OPTIONS_GHC ddumpderiv #}
module Works ...This bug is present on GHC 8.0.1, 8.0.2, 8.2.1 and HEAD, and originally noted in #13738\##13748. Take this code:
```hs
{# LANGUAGE GeneralizedNewtypeDeriving #}
{# LANGUAGE PolyKinds #}
{# OPTIONS_GHC ddumpderiv #}
module Works where
newtype Wrap f a = Wrap (f a) deriving C
class C f where
c :: f a
```
When you compile it with GHC 8.0.2, you'll get this unsavory output:
```
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Works ( Works.hs, interpreted )
==================== Derived instances ====================
Derived instances:
instance forall k_a14U (f_a14V :: k_a14U > *).
Works.C f_a14V =>
Works.C (Works.Wrap f_a14V) where
Works.c
= GHC.Prim.coerce
@(forall (a_a13F :: k_a14u). f_a13G a_a13F)
@(forall (a_a13F :: k_a14u). Works.Wrap f_a13G a_a13F)
Works.c
GHC.Generics representation types:
```
This is wrong, since the quantified variables in the instance head (`k_a14U` and `f_a14V`) do not match the occurrences that they bind (`k_a14u` and `f_a13G`). This is somewhat easier to see on GHC 8.2.1 or HEAD, since the binding sites are printed without uniques:
```
GHCi, version 8.3.20170516: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Works ( Works.hs, interpreted )
==================== Derived instances ====================
Derived class instances:
instance forall k (f :: k > *).
Works.C f =>
Works.C (Works.Wrap f) where
Works.c
= GHC.Prim.coerce
@(forall (a_a1tD :: k_a1uE). f_a1tE a_a1tD)
@(forall (a_a1tD :: k_a1uE). Works.Wrap f_a1tE a_a1tD)
Works.c
Derived type family instances:
```
<details><summary>Trac metadata</summary>
 Trac field  Value 
    
 Version  8.0.1 
 Type  Bug 
 TypeOfFailure  OtherFailure 
 Priority  normal 
 Resolution  Unresolved 
 Component  Compiler (Type checker) 
 Test case  
 Differential revisions  
 BlockedBy  
 Related  
 Blocking  
 CC  
 Operating system  
 Architecture  
</details>
<! {"blocked_by":[],"summary":"Variables prettyprinted from ddumpderiv are not scoped properly","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This bug is present on GHC 8.0.1, 8.0.2, 8.2.1 and HEAD, and originally noted in https://ghc.haskell.org/trac/ghc/ticket/13738#comment:2. Take this code:\r\n\r\n{{{#!hs\r\n{# LANGUAGE GeneralizedNewtypeDeriving #}\r\n{# LANGUAGE PolyKinds #}\r\n{# OPTIONS_GHC ddumpderiv #}\r\nmodule Works where\r\n\r\nnewtype Wrap f a = Wrap (f a) deriving C\r\n\r\nclass C f where\r\n c :: f a\r\n}}}\r\n\r\nWhen you compile it with GHC 8.0.2, you'll get this unsavory output:\r\n\r\n{{{\r\nGHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Works ( Works.hs, interpreted )\r\n\r\n==================== Derived instances ====================\r\nDerived instances:\r\n instance forall k_a14U (f_a14V :: k_a14U > *).\r\n Works.C f_a14V =>\r\n Works.C (Works.Wrap f_a14V) where\r\n Works.c\r\n = GHC.Prim.coerce\r\n @(forall (a_a13F :: k_a14u). f_a13G a_a13F)\r\n @(forall (a_a13F :: k_a14u). Works.Wrap f_a13G a_a13F)\r\n Works.c\r\n \r\n\r\nGHC.Generics representation types:\r\n}}}\r\n\r\nThis is wrong, since the quantified variables in the instance head (`k_a14U` and `f_a14V`) do not match the occurrences that they bind (`k_a14u` and `f_a13G`). This is somewhat easier to see on GHC 8.2.1 or HEAD, since the binding sites are printed without uniques:\r\n\r\n{{{\r\nGHCi, version 8.3.20170516: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Works ( Works.hs, interpreted )\r\n\r\n==================== Derived instances ====================\r\nDerived class instances:\r\n instance forall k (f :: k > *).\r\n Works.C f =>\r\n Works.C (Works.Wrap f) where\r\n Works.c\r\n = GHC.Prim.coerce\r\n @(forall (a_a1tD :: k_a1uE). f_a1tE a_a1tD)\r\n @(forall (a_a1tD :: k_a1uE). Works.Wrap f_a1tE a_a1tD)\r\n Works.c\r\n \r\n\r\nDerived type family instances:\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} >https://gitlab.haskell.org/ghc/ghc//issues/13731DeriveFunctor and friends don't understand type families20200608T17:11:37ZSophie TaylorDeriveFunctor and friends don't understand type families```hs
{# LANGUAGE DeriveFunctor #}
{# LANGUAGE FlexibleInstances #}
{# LANGUAGE GADTs #}
{# LANGUAGE StandaloneDeriving #}
{# LANGUAGE TypeFamilies #}
data Test ext a where
Foo :: a > Test ext a
Extend :: (ExtensionType e...```hs
{# LANGUAGE DeriveFunctor #}
{# LANGUAGE FlexibleInstances #}
{# LANGUAGE GADTs #}
{# LANGUAGE StandaloneDeriving #}
{# LANGUAGE TypeFamilies #}
data Test ext a where
Foo :: a > Test ext a
Extend :: (ExtensionType ext a) > Test ext a
type family ExtensionType ext a
data ListExtension
type instance ExtensionType ListExtension a = [a]
deriving instance Functor (Test ListExtension)
{
a.hs:15:1: error:
• Can't make a derived instance of ‘Functor (Test ListExtension)’:
Constructor ‘Extend’ must use the type variable only as the last argument of a data type
• In the standalone deriving instance for
‘Functor (Test ListExtension)’

15  deriving instance Functor (Test ListExtension)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Failed, modules loaded: none.
}
```
<details><summary>Trac metadata</summary>
 Trac field  Value 
    
 Version  8.2.1rc2 
 Type  Bug 
 TypeOfFailure  OtherFailure 
 Priority  normal 
 Resolution  Unresolved 
 Component  Compiler 
 Test case  
 Differential revisions  
 BlockedBy  
 Related  
 Blocking  
 CC  
 Operating system  
 Architecture  
</details>
<! {"blocked_by":[],"summary":"DeriveFunctor and friends don't understand type families","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{# LANGUAGE DeriveFunctor #}\r\n{# LANGUAGE FlexibleInstances #}\r\n{# LANGUAGE GADTs #}\r\n{# LANGUAGE StandaloneDeriving #}\r\n{# LANGUAGE TypeFamilies #}\r\n\r\ndata Test ext a where\r\n Foo :: a > Test ext a\r\n Extend :: (ExtensionType ext a) > Test ext a\r\n\r\ntype family ExtensionType ext a\r\ndata ListExtension\r\ntype instance ExtensionType ListExtension a = [a]\r\n\r\nderiving instance Functor (Test ListExtension)\r\n\r\n{\r\n\r\na.hs:15:1: error:\r\n • Can't make a derived instance of ‘Functor (Test ListExtension)’:\r\n Constructor ‘Extend’ must use the type variable only as the last argument of a data type\r\n • In the standalone deriving instance for\r\n ‘Functor (Test ListExtension)’\r\n \r\n15  deriving instance Functor (Test ListExtension)\r\n  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r\nFailed, modules loaded: none.\r\n}\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} >https://gitlab.haskell.org/ghc/ghc//issues/13465Foldable deriving treatment of tuples is too surprising20200123T19:31:53ZDavid FeuerFoldable deriving treatment of tuples is too surprising```
*> :set XDeriveFoldable
*> data Foo a = Foo ((a,a),a) deriving Foldable
*> length ((1,1),1)
1 ...```
*> :set XDeriveFoldable
*> data Foo a = Foo ((a,a),a) deriving Foldable
*> length ((1,1),1)
1
*> length $ Foo ((1,1),1)
3
```
I think the right thing is probably to refuse to derive `Foldable` if components of a tuple other than the last one may contain the type variable we're looking for.
<details><summary>Trac metadata</summary>
 Trac field  Value 
    
 Version  8.1 
 Type  Bug 
 TypeOfFailure  OtherFailure 
 Priority  normal 
 Resolution  Unresolved 
 Component  Compiler 
 Test case  
 Differential revisions  
 BlockedBy  
 Related  
 Blocking  
 CC  
 Operating system  
 Architecture  
</details>
<! {"blocked_by":[],"summary":"Foldable deriving treatment of tuples is too surprising","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n*> :set XDeriveFoldable\r\n*> data Foo a = Foo ((a,a),a) deriving Foldable \r\n*> length ((1,1),1)\r\n1 \r\n*> length $ Foo ((1,1),1)\r\n3 \r\n}}}\r\n\r\nI think the right thing is probably to refuse to derive `Foldable` if components of a tuple other than the last one may contain the type variable we're looking for.","type_of_failure":"OtherFailure","blocking":[]} >https://gitlab.haskell.org/ghc/ghc//issues/13403Derive instances (Applicative, Monad, ...) for structures lifted over functors20190707T18:22:02ZIcelandjackDerive instances (Applicative, Monad, ...) for structures lifted over functorsI'll start small: Given that we know how to define various instances for [Product](https://hackage.haskell.org/package/base4.9.1.0/docs/DataFunctorProduct.html) GHC could do it automatically.
```hs
data P f g a = f a ::: g a deriving...I'll start small: Given that we know how to define various instances for [Product](https://hackage.haskell.org/package/base4.9.1.0/docs/DataFunctorProduct.html) GHC could do it automatically.
```hs
data P f g a = f a ::: g a deriving (Functor, Applicative, Alternative)
{
instance (Applicative f, Applicative g) => Applicative (P f g) where
pure x = pure x ::: pure x
(f:::g) <*> (x:::y) = (f <*> x) ::: (g <*> y)
}
```
And for specific constructors as well
```hs
data Q a = [a] :*: Maybe a deriving (Functor, Applicative, Alternative)
{
instance Applicative Q where
pure x = [x] :*: Just x
(f:*:g) <*> (x:*:y) = (f <*> x) :*: (g <*> y)
}
```
## Alternative
Use `GeneralizedNewtypeDeriving`
```hs
newtype Q a = Q (Product [] Maybe a)
deriving (Functor, Applicative, Alternative)
pattern (:*:) :: [a] > Maybe a > Q a
pattern a :*: b = Q (Pair a b)
```
## Future Work
This should work for a combination of various things, using `Const _` deprives us of `Alternative`
```hs
newtype U e a = U (([] `Product` Maybe `Product` Const e) a)
deriving (Functor, Applicative)
```
using sums where [one summand is identity](https://hackage.haskell.org/package/transformers0.5.4.0/docs/ControlApplicativeLift.html) gives us `Applicative` / `Alternative`
```hs
 data Lift f a = Pure a  Other (f a)
import Control.Applicative.Lift
data V a = V ((Lift [] `Product` Maybe) a)
deriving (Functor, Applicative, Alternative)
```
I want to be able to write this directly
```hs
data U e a = U [a] (Maybe a) (Const e a)
deriving (Functor, Applicative)
data V a
= VL a (Maybe a)
 VR [a] (Maybe a)
deriving (Functor, Applicative, Alternative)
```
## Future, Future Work ==
[leftKan extension](https://hackage.haskell.org/package/kanextensions5.0.1/docs/DataFunctorKanLan.html)
```hs
data Lan g h a where
Lan :: (g b > a) > h b > Lan g h a
deriving (Functor, Applicative)
```
[codensity](https://hackage.haskell.org/package/kanextensions5.0.1/docs/ControlMonadCodensity.html)
```hs
data Endo a = Endo (a > a)
newtype CodEndo a = CE (forall xx. (a > Endo xx) > Endo xx)
deriving (Functor, Applicative, Monad)
```
and [comonad](https://hackage.haskell.org/package/free4.12.4/docs/ControlComonadCofree.html)
```hs
data Rose a = a :< [Rose a]
deriving (Functor, Applicative, Monad, Comonad, ...)
```
<details><summary>Trac metadata</summary>
 Trac field  Value 
    
 Version  8.0.1 
 Type  Bug 
 TypeOfFailure  OtherFailure 
 Priority  normal 
 Resolution  Unresolved 
 Component  Compiler 
 Test case  
 Differential revisions  
 BlockedBy  
 Related  
 Blocking  
 CC  
 Operating system  
 Architecture  
</details>
<! {"blocked_by":[],"summary":"Derive instances (Applicative, Monad, ...) for structures lifted over functors","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'll start small: Given that we know how to define various instances for [https://hackage.haskell.org/package/base4.9.1.0/docs/DataFunctorProduct.html Product] GHC could do it automatically.\r\n\r\n{{{#!hs\r\ndata P f g a = f a ::: g a deriving (Functor, Applicative, Alternative)\r\n\r\n{\r\ninstance (Applicative f, Applicative g) => Applicative (P f g) where\r\n pure x = pure x ::: pure x\r\n (f:::g) <*> (x:::y) = (f <*> x) ::: (g <*> y)\r\n}\r\n}}}\r\n\r\nAnd for specific constructors as well\r\n\r\n{{{#!hs\r\ndata Q a = [a] :*: Maybe a deriving (Functor, Applicative, Alternative)\r\n\r\n{\r\ninstance Applicative Q where\r\n pure x = [x] :*: Just x\r\n (f:*:g) <*> (x:*:y) = (f <*> x) :*: (g <*> y)\r\n}\r\n}}}\r\n\r\n== Alternative ==\r\n\r\nUse `GeneralizedNewtypeDeriving`\r\n\r\n{{{#!hs\r\nnewtype Q a = Q (Product [] Maybe a)\r\n deriving (Functor, Applicative, Alternative)\r\n\r\npattern (:*:) :: [a] > Maybe a > Q a\r\npattern a :*: b = Q (Pair a b)\r\n}}}\r\n\r\n== Future Work ==\r\n\r\nThis should work for a combination of various things, using `Const _` deprives us of `Alternative`\r\n\r\n{{{#!hs\r\nnewtype U e a = U (([] `Product` Maybe `Product` Const e) a)\r\n deriving (Functor, Applicative)\r\n}}}\r\n\r\nusing sums where [https://hackage.haskell.org/package/transformers0.5.4.0/docs/ControlApplicativeLift.html one summand is identity] gives us `Applicative` / `Alternative`\r\n\r\n{{{#!hs\r\n data Lift f a = Pure a  Other (f a)\r\nimport Control.Applicative.Lift\r\n\r\ndata V a = V ((Lift [] `Product` Maybe) a) \r\n deriving (Functor, Applicative, Alternative)\r\n}}}\r\n\r\nI want to be able to write this directly\r\n\r\n{{{#!hs\r\ndata U e a = U [a] (Maybe a) (Const e a)\r\n deriving (Functor, Applicative)\r\n\r\ndata V a\r\n = VL a (Maybe a)\r\n  VR [a] (Maybe a)\r\n deriving (Functor, Applicative, Alternative)\r\n}}}\r\n\r\n== Future, Future Work == \r\n\r\n[https://hackage.haskell.org/package/kanextensions5.0.1/docs/DataFunctorKanLan.html leftKan extension]\r\n\r\n{{{#!hs\r\ndata Lan g h a where\r\n Lan :: (g b > a) > h b > Lan g h a\r\n deriving (Functor, Applicative)\r\n}}}\r\n\r\n[https://hackage.haskell.org/package/kanextensions5.0.1/docs/ControlMonadCodensity.html codensity]\r\n\r\n{{{#!hs\r\ndata Endo a = Endo (a > a)\r\n\r\nnewtype CodEndo a = CE (forall xx. (a > Endo xx) > Endo xx)\r\n deriving (Functor, Applicative, Monad)\r\n}}}\r\n\r\nand [https://hackage.haskell.org/package/free4.12.4/docs/ControlComonadCofree.html comonad]\r\n\r\n{{{#!hs\r\ndata Rose a = a :< [Rose a]\r\n deriving (Functor, Applicative, Monad, Comonad, ...)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} >https://gitlab.haskell.org/ghc/ghc//issues/13327Figure out how to make sense of Data instances for polykinded datatypes20200528T11:41:57ZRyan ScottFigure out how to make sense of Data instances for polykinded datatypesSomething's funny with `Data.Data`. In particular, what instance do you expect when you write this?
```hs
data T phantom = T
deriving Data
```
You might expect:
...Something's funny with `Data.Data`. In particular, what instance do you expect when you write this?
```hs
data T phantom = T
deriving Data
```
You might expect:
```hs
instance Typeable phantom => Data (T phantom) where
...
```
And indeed, it is possible to define a `Data` instance like this. But in practice, GHC actually derives this instance:
```hs
instance Data phantom => Data (T phantom) where
...
dataCast1 f = gcast1 f
```
The reason is because GHC has special cases for when it derives `Data` instances for datatypes of kind `* > *` or `* > * > *`. These special cases cause the derived `Data` instances to insert definitions for `dataCast1` or `dataCast2`, respectively, and their implementations (`gcast1` or `gcast2`, respectively) require the stronger instance context. See #4028 for a longer discussion about this.
Things get far less predictable when you throw in `PolyKinds`, however. If you try this instead:
```hs
data T (phantom :: k) = T
deriving Data
```
Then you do //not// get `instance Data phantom => Data (T phantom)` as above. Instead, you get this:
```hs
instance (Typeable k, Typeable (phantom :: k)) => Data (T phantom) where
...
 No implementation for dataCast1
```
As it turns out, GHC's specialcasing for deriving `Data` is not privy to datatypes of kind `k > *` or `k1 > k2 > *`, just `* > *` and `* > * > *`.
This is all a bit disconcerting because if you look at `Data.Data`, there are many instances of the flavor:
```hs
deriving instance Data (p :: *) => Data (U1 p)  U1 :: k > *
```
This makes sense in a pre`PolyKinds` world, but really, the most general type for this `Data` instance would be:
```hs
deriving instance (Typeable k, Typeable (p :: k)) => Data (U1 p)
```
Even worse, choosing the less polymorphic instance `Data (p :: *) => Data (U1 p)` via `StandaloneDeriving` doesn't even cause GHC to emit a definition for `dataCast1`—it just restricts the kind with no benefit!
This whole situation doesn't sit well with me, especially since as we add more polykinded `Data` instances to `Data.Data`, we have to ask ourselves each time what the "right" `Data` instance is. It would be great if we could answer these questions:
1. Should we expand the specialcasing for datatypes of kind `k > *` or `k1 > k2 > *`? Or do `dataCast1` and `dataCast2` even make sense for polykinded datatypes?
1. Is there a way to modify `DeriveDataTypeable` such that emitting definitions for `dataCast1` and `dataCast2` don't require us to default some kind variables to `*`? Perhaps `TypeInType` could help us here somehow.
<details><summary>Trac metadata</summary>
 Trac field  Value 
    
 Version  8.0.1 
 Type  Bug 
 TypeOfFailure  OtherFailure 
 Priority  normal 
 Resolution  Unresolved 
 Component  libraries/base 
 Test case  
 Differential revisions  
 BlockedBy  
 Related  
 Blocking  
 CC  dreixel 
 Operating system  
 Architecture  
</details>
<! {"blocked_by":[],"summary":"Figure out how to make sense of Data instances for polykinded datatypes","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["dreixel"],"type":"Bug","description":"Something's funny with `Data.Data`. In particular, what instance do you expect when you write this?\r\n\r\n{{{#!hs\r\ndata T phantom = T \r\n deriving Data\r\n}}}\r\n\r\nYou might expect:\r\n\r\n{{{#!hs\r\ninstance Typeable phantom => Data (T phantom) where\r\n ...\r\n}}}\r\n\r\nAnd indeed, it is possible to define a `Data` instance like this. But in practice, GHC actually derives this instance:\r\n\r\n{{{#!hs\r\ninstance Data phantom => Data (T phantom) where\r\n ...\r\n dataCast1 f = gcast1 f\r\n}}}\r\n\r\nThe reason is because GHC has special cases for when it derives `Data` instances for datatypes of kind `* > *` or `* > * > *`. These special cases cause the derived `Data` instances to insert definitions for `dataCast1` or `dataCast2`, respectively, and their implementations (`gcast1` or `gcast2`, respectively) require the stronger instance context. See #4028 for a longer discussion about this.\r\n\r\nThings get far less predictable when you throw in `PolyKinds`, however. If you try this instead:\r\n\r\n{{{#!hs\r\ndata T (phantom :: k) = T\r\n deriving Data\r\n}}}\r\n\r\nThen you do //not// get `instance Data phantom => Data (T phantom)` as above. Instead, you get this:\r\n\r\n{{{#!hs\r\ninstance (Typeable k, Typeable (phantom :: k)) => Data (T phantom) where\r\n ...\r\n  No implementation for dataCast1\r\n}}}\r\n\r\nAs it turns out, GHC's specialcasing for deriving `Data` is not privy to datatypes of kind `k > *` or `k1 > k2 > *`, just `* > *` and `* > * > *`.\r\n\r\nThis is all a bit disconcerting because if you look at `Data.Data`, there are many instances of the flavor:\r\n\r\n{{{#!hs\r\nderiving instance Data (p :: *) => Data (U1 p)  U1 :: k > *\r\n}}}\r\n\r\nThis makes sense in a pre`PolyKinds` world, but really, the most general type for this `Data` instance would be:\r\n\r\n{{{#!hs\r\nderiving instance (Typeable k, Typeable (p :: k)) => Data (U1 p)\r\n}}}\r\n\r\nEven worse, choosing the less polymorphic instance `Data (p :: *) => Data (U1 p)` via `StandaloneDeriving` doesn't even cause GHC to emit a definition for `dataCast1`—it just restricts the kind with no benefit!\r\n\r\nThis whole situation doesn't sit well with me, especially since as we add more polykinded `Data` instances to `Data.Data`, we have to ask ourselves each time what the \"right\" `Data` instance is. It would be great if we could answer these questions:\r\n\r\n1. Should we expand the specialcasing for datatypes of kind `k > *` or `k1 > k2 > *`? Or do `dataCast1` and `dataCast2` even make sense for polykinded datatypes?\r\n2. Is there a way to modify `DeriveDataTypeable` such that emitting definitions for `dataCast1` and `dataCast2` don't require us to default some kind variables to `*`? Perhaps `TypeInType` could help us here somehow.","type_of_failure":"OtherFailure","blocking":[]} >https://gitlab.haskell.org/ghc/ghc//issues/13280Consider deriving more Foldable methods20210331T13:19:59ZDavid FeuerConsider deriving more Foldable methodsWe currently derive `foldMap` and `foldr`, but some others may deserve attention as well.
 The most critical spots are probably `length` and `null`. Deriving these instead of using the defaults can change the orders of growth! Given `d...We currently derive `foldMap` and `foldr`, but some others may deserve attention as well.
 The most critical spots are probably `length` and `null`. Deriving these instead of using the defaults can change the orders of growth! Given `data Tree a = Bin !(Tree a) a !(Tree a)  Tip`, we surely don't want `null` to traverse the whole spine of the tree when it's quite immediately obvious that `Bin` is never null. And if a constructor contains a type with a very efficient `length` or `null` implementation (e.g., one that stores its own size), we certainly want to use that.
 `foldl` typically ends up with rather different code than `foldr` (for a recursive type) even after simplification. We need to check whether this has a performance impact, but my bet is that it will in cases where the optimizer can't understand what's going on well enough.
 `foldl'` and `foldr'` are a bit tricky. Ideally, if we have something like `data T a = C (G a) a  ...` then we'd like to be able to use `G`'s `foldl'` definition to define `T`'s. Unfortunately, different types in the wild have different `foldl'` semantics (and indeed the semantics for `[]` changed by mistake fairly recently). So we have to decide to what extent the derived semantics should depend on the choices of included types. I think we should probably just depend, because that seems likely what people will expect and want.
<details><summary>Trac metadata</summary>
 Trac field  Value 
    
 Version  8.0.1 
 Type  Task 
 TypeOfFailure  OtherFailure 
 Priority  normal 
 Resolution  Unresolved 
 Component  Compiler 
 Test case  
 Differential revisions  
 BlockedBy  
 Related  
 Blocking  
 CC  
 Operating system  
 Architecture  
</details>
<! {"blocked_by":[],"summary":"Consider deriving more Foldable methods","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"We currently derive `foldMap` and `foldr`, but some others may deserve attention as well.\r\n\r\n* The most critical spots are probably `length` and `null`. Deriving these instead of using the defaults can change the orders of growth! Given `data Tree a = Bin !(Tree a) a !(Tree a)  Tip`, we surely don't want `null` to traverse the whole spine of the tree when it's quite immediately obvious that `Bin` is never null. And if a constructor contains a type with a very efficient `length` or `null` implementation (e.g., one that stores its own size), we certainly want to use that.\r\n\r\n* `foldl` typically ends up with rather different code than `foldr` (for a recursive type) even after simplification. We need to check whether this has a performance impact, but my bet is that it will in cases where the optimizer can't understand what's going on well enough.\r\n\r\n* `foldl'` and `foldr'` are a bit tricky. Ideally, if we have something like `data T a = C (G a) a  ...` then we'd like to be able to use `G`'s `foldl'` definition to define `T`'s. Unfortunately, different types in the wild have different `foldl'` semantics (and indeed the semantics for `[]` changed by mistake fairly recently). So we have to decide to what extent the derived semantics should depend on the choices of included types. I think we should probably just depend, because that seems likely what people will expect and want.","type_of_failure":"OtherFailure","blocking":[]} >David FeuerDavid Feuerhttps://gitlab.haskell.org/ghc/ghc//issues/12860GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an ...20190801T11:47:53ZRyan ScottGeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loopThis worked in GHC 7.6.3, but ever since GHC 7.8, this code will cause the typechecker to loop infinitely:
```hs
{# LANGUAGE FunctionalDependencies #}
{# LANGUAGE GeneralizedNewtypeDeriving #}
{# LANGUAGE MultiParamTypeClasses #}
...This worked in GHC 7.6.3, but ever since GHC 7.8, this code will cause the typechecker to loop infinitely:
```hs
{# LANGUAGE FunctionalDependencies #}
{# LANGUAGE GeneralizedNewtypeDeriving #}
{# LANGUAGE MultiParamTypeClasses #}
module Bug where
class C a b  a > b where
c :: a > Int
newtype Foo a = Foo a
deriving (C b)
```
<details><summary>Trac metadata</summary>
 Trac field  Value 
    
 Version  8.0.1 
 Type  Bug 
 TypeOfFailure  OtherFailure 
 Priority  normal 
 Resolution  Unresolved 
 Component  Compiler (Type checker) 
 Test case  
 Differential revisions  
 BlockedBy  
 Related  
 Blocking  
 CC  
 Operating system  
 Architecture  
</details>
<! {"blocked_by":[],"summary":"GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This worked in GHC 7.6.3, but ever since GHC 7.8, this code will cause the typechecker to loop infinitely:\r\n\r\n{{{#!hs\r\n{# LANGUAGE FunctionalDependencies #}\r\n{# LANGUAGE GeneralizedNewtypeDeriving #}\r\n{# LANGUAGE MultiParamTypeClasses #}\r\nmodule Bug where\r\n\r\nclass C a b  a > b where\r\n c :: a > Int\r\n\r\nnewtype Foo a = Foo a\r\n deriving (C b)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} >https://gitlab.haskell.org/ghc/ghc//issues/12639Inconsistent treatment of FlexibleInstances and MPTCs with standard vs. flexi...20190707T18:25:44ZDavid FeuerInconsistent treatment of FlexibleInstances and MPTCs with standard vs. flexible derivingGiven `{# LANGUAGE GeneralizedNewtypeDeriving #}`, I can write
```hs
import Control.Monad.State.Strict
newtype Foo s m a = Foo (StateT s m a)
deriving (Functor, Applicative, Monad, MonadState s)
```
However, if I want to use `Stan...Given `{# LANGUAGE GeneralizedNewtypeDeriving #}`, I can write
```hs
import Control.Monad.State.Strict
newtype Foo s m a = Foo (StateT s m a)
deriving (Functor, Applicative, Monad, MonadState s)
```
However, if I want to use `StandaloneDeriving` to make the `MonadState` instance more explicit,
```hs
deriving instance Monad m => MonadState s (Foo s m)
```
I suddenly need to add `FlexibleInstances` and `MultiParamTypeClasses`.
In my personal opinion, the most sensible way to handle this is to change two things in two different directions:
1. Allow MPTC instance declarations (but not class declarations) without `MultiParamTypeClasses`.
1. Require `FlexibleInstances` for standard deriving clauses when they would be required for standalone deriving declarations.
<details><summary>Trac metadata</summary>
 Trac field  Value 
    
 Version  8.1 
 Type  FeatureRequest 
 TypeOfFailure  OtherFailure 
 Priority  normal 
 Resolution  Unresolved 
 Component  Compiler (Type checker) 
 Test case  
 Differential revisions  
 BlockedBy  
 Related  
 Blocking  
 CC  
 Operating system  
 Architecture  
</details>
<! {"blocked_by":[],"summary":"Inconsistent treatment of FlexibleInstances and MPTCs with standard vs. flexible deriving","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Given `{# LANGUAGE GeneralizedNewtypeDeriving #}`, I can write\r\n\r\n{{{#!hs\r\nimport Control.Monad.State.Strict\r\n\r\nnewtype Foo s m a = Foo (StateT s m a)\r\n deriving (Functor, Applicative, Monad, MonadState s)\r\n}}}\r\n\r\nHowever, if I want to use `StandaloneDeriving` to make the `MonadState` instance more explicit,\r\n\r\n{{{#!hs\r\nderiving instance Monad m => MonadState s (Foo s m)\r\n}}}\r\n\r\nI suddenly need to add `FlexibleInstances` and `MultiParamTypeClasses`.\r\n\r\nIn my personal opinion, the most sensible way to handle this is to change two things in two different directions:\r\n\r\n1. Allow MPTC instance declarations (but not class declarations) without `MultiParamTypeClasses`.\r\n\r\n2. Require `FlexibleInstances` for standard deriving clauses when they would be required for standalone deriving declarations.","type_of_failure":"OtherFailure","blocking":[]} >