GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:02:46Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/3690GHC panics on a crazy type signature2019-07-07T19:02:46ZBorisGHC panics on a crazy type signature```
x :: [Enum a => (forall a. Num a => a)]
x = []
```
I have NO idea what that would mean or whatever it makes sense at all, but it fails with:
```
: panic! (the 'impossible' happened)
(GHC version 6.10.4 for i386-unknown-mingw32)...```
x :: [Enum a => (forall a. Num a => a)]
x = []
```
I have NO idea what that would mean or whatever it makes sense at all, but it fails with:
```
: panic! (the 'impossible' happened)
(GHC version 6.10.4 for i386-unknown-mingw32):
TcTyFuns.flattenType: unexpected PredType
```
And it said I should report it. :)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.4 |
| 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":"GHC panics on a crazy type signature","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nx :: [Enum a => (forall a. Num a => a)]\r\nx = []\r\n}}}\r\n\r\nI have NO idea what that would mean or whatever it makes sense at all, but it fails with:\r\n\r\n{{{\r\n: panic! (the 'impossible' happened)\r\n (GHC version 6.10.4 for i386-unknown-mingw32):\r\n TcTyFuns.flattenType: unexpected PredType\r\n}}}\r\n\r\nAnd it said I should report it. :)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3696Incorrect type inferred with -fwarn-missing-signatures and a type class2019-07-07T19:02:44ZsplIncorrect type inferred with -fwarn-missing-signatures and a type classThe inferred type using -fwarn-missing-signatures and a type class is too general for top-level values.
Here is a simplified example:
```
{-# OPTIONS -Wall #-}
class C a where c :: a
instance C Int where c = 37
def = c
use :: Int
u...The inferred type using -fwarn-missing-signatures and a type class is too general for top-level values.
Here is a simplified example:
```
{-# OPTIONS -Wall #-}
class C a where c :: a
instance C Int where c = 37
def = c
use :: Int
use = def
```
The inferred type reported by GHCi when -fwarn-missing-signatures is enabled is:
```
Ex.hs:7:0:
Warning: Definition but no type signature for `def'
Inferred type: def :: a
```
The most general possible type here is `C a => a`. When asking GHCi for the type of `def`, it reports `Int`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | leather@cs.uu.nl |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect type inferred with -fwarn-missing-signatures and a type class","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["leather@cs.uu.nl"],"type":"Bug","description":"The inferred type using -fwarn-missing-signatures and a type class is too general for top-level values.\r\n\r\nHere is a simplified example:\r\n\r\n{{{\r\n{-# OPTIONS -Wall #-}\r\n\r\nclass C a where c :: a\r\n\r\ninstance C Int where c = 37\r\n\r\ndef = c\r\n\r\nuse :: Int\r\nuse = def\r\n}}}\r\n\r\nThe inferred type reported by GHCi when -fwarn-missing-signatures is enabled is:\r\n\r\n{{{\r\nEx.hs:7:0:\r\n Warning: Definition but no type signature for `def'\r\n Inferred type: def :: a\r\n}}}\r\n\r\nThe most general possible type here is {{{C a => a}}}. When asking GHCi for the type of {{{def}}}, it reports {{{Int}}}.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3700Being instance of Monoid is not checked2019-07-07T19:02:43ZBoris LykahBeing instance of Monoid is not checkedIt is possible pass not only instances of Monoid to tell function and load the file with GHCi. GHCi shows type f :: (MonadWriter ((a -\> b) -\> \[a\] -\> \[b\]) m) =\> t -\> m ()
```
f _ = tell map
```
However, if code is
```
f = tell...It is possible pass not only instances of Monoid to tell function and load the file with GHCi. GHCi shows type f :: (MonadWriter ((a -\> b) -\> \[a\] -\> \[b\]) m) =\> t -\> m ()
```
f _ = tell map
```
However, if code is
```
f = tell map
```
GHCi shows type error(no instance) as expected.
It seems very strange that type correctness depends on number of parameters for function that is not used anywhere.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.3 |
| 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":"Being instance of Monoid is not checked","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":["Monoid,","Writer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It is possible pass not only instances of Monoid to tell function and load the file with GHCi. GHCi shows type f :: (MonadWriter ((a -> b) -> [a] -> [b]) m) => t -> m ()\r\n{{{\r\nf _ = tell map\r\n}}}\r\nHowever, if code is\r\n{{{\r\nf = tell map\r\n}}}\r\nGHCi shows type error(no instance) as expected.\r\n\r\nIt seems very strange that type correctness depends on number of parameters for function that is not used anywhere.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3734overlapping orphan instances behave like incoherent without warning/error2019-07-07T19:02:32ZTomáš Janoušekoverlapping orphan instances behave like incoherent without warning/errorConsider these three modules:
```
module A where
class (Show a) => A a
data A' = A' deriving (Show)
instance A A'
data A'' = A'' deriving (Show)
instance A A''
print_a :: (A a) => a -> IO ()
print_a a = print a
```
```
{-# LANGUAGE...Consider these three modules:
```
module A where
class (Show a) => A a
data A' = A' deriving (Show)
instance A A'
data A'' = A'' deriving (Show)
instance A A''
print_a :: (A a) => a -> IO ()
print_a a = print a
```
```
{-# LANGUAGE FlexibleInstances, OverlappingInstances #-}
module B where
import A
data B a = B a deriving (Show)
instance (A a) => A (B a)
```
```
{-# LANGUAGE FlexibleInstances, OverlappingInstances #-}
module Main where
import A
import B
instance Show (B A') where
show _ = "kokodak"
instance Show (B A'') where
show _ = "brekeke"
instance A (B A'')
main :: IO ()
main = do
print (B A')
print_a (B A')
putStrLn ""
print (B A'')
print_a (B A'')
```
Without understanding a thing about dictionaries, I would expect that if this actually compiles (which I now understand it should not), I'd get `"kokodak kokodak brekeke brekeke"` as output, but I got `"kokodak B A' brekeke brekeke"` instead.
I figured that even though I redefined `Show (B A')`, the `A (B a)` instance was defined in module `B` and consisted of the original `Show` dictionary. If I move the `Show (B A')` instance to module B, ghc complains that the definition of `A (B a)` depends on the instatiation of `a` and refuses to compile it, unless I enable `IncoherentInstances`.
The problem here is that if the `Show (B A')` instance is orphan, I get the `IncoherentInstances` behaviour for free without any warning or error, giving me the false feeling that the code is actually OK. Is it possible that ghc gives an error in this case, and may the documentation mention that Overlapping + Orphan =\> Incoherent?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.4 |
| 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":"overlapping orphan instances behave like incoherent without warning/error","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider these three modules:\r\n\r\n{{{\r\nmodule A where\r\n\r\nclass (Show a) => A a\r\n\r\ndata A' = A' deriving (Show)\r\ninstance A A'\r\n\r\ndata A'' = A'' deriving (Show)\r\ninstance A A''\r\n\r\nprint_a :: (A a) => a -> IO ()\r\nprint_a a = print a\r\n}}}\r\n\r\n{{{\r\n{-# LANGUAGE FlexibleInstances, OverlappingInstances #-}\r\nmodule B where\r\n\r\nimport A\r\n\r\ndata B a = B a deriving (Show)\r\ninstance (A a) => A (B a)\r\n}}}\r\n\r\n{{{\r\n{-# LANGUAGE FlexibleInstances, OverlappingInstances #-}\r\nmodule Main where\r\n\r\nimport A\r\nimport B\r\n\r\ninstance Show (B A') where\r\n show _ = \"kokodak\"\r\n\r\ninstance Show (B A'') where\r\n show _ = \"brekeke\"\r\n\r\ninstance A (B A'')\r\n\r\nmain :: IO ()\r\nmain = do\r\n print (B A')\r\n print_a (B A')\r\n putStrLn \"\"\r\n print (B A'')\r\n print_a (B A'')\r\n}}}\r\n\r\nWithout understanding a thing about dictionaries, I would expect that if this actually compiles (which I now understand it should not), I'd get `\"kokodak kokodak brekeke brekeke\"` as output, but I got `\"kokodak B A' brekeke brekeke\"` instead.\r\n\r\nI figured that even though I redefined `Show (B A')`, the `A (B a)` instance was defined in module `B` and consisted of the original `Show` dictionary. If I move the `Show (B A')` instance to module B, ghc complains that the definition of `A (B a)` depends on the instatiation of `a` and refuses to compile it, unless I enable `IncoherentInstances`.\r\n\r\nThe problem here is that if the `Show (B A')` instance is orphan, I get the `IncoherentInstances` behaviour for free without any warning or error, giving me the false feeling that the code is actually OK. Is it possible that ghc gives an error in this case, and may the documentation mention that Overlapping + Orphan => Incoherent?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3787GHC 6.12.1 panic2019-07-07T19:02:10ZGhost UserGHC 6.12.1 panicGHC 6.12.1 reports the following when compiling the attached module:
```
$ ghc --make Trampoline.hs -O[1 of 1] Compiling Control.Concurrent.SCC.Trampoline ( Trampoline.hs, Trampoline.o )
ghc: panic! (the 'impossible' happened)
(GHC ve...GHC 6.12.1 reports the following when compiling the attached module:
```
$ ghc --make Trampoline.hs -O[1 of 1] Compiling Control.Concurrent.SCC.Trampoline ( Trampoline.hs, Trampoline.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.12.1 for x86_64-unknown-linux):
expectJust chooseExternalIds: ds_d1HQ
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
So I'm dutifully reporting it. The module in question could probably be easily trimmed down, but I'm too sleepy at the moment. Let me know if you need that.Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/3819keeping RelaxedPolyRec as optional feature can help spotting infinite recursion2019-07-07T19:02:00Zguestkeeping RelaxedPolyRec as optional feature can help spotting infinite recursionThis is a ticket you have nothing to do about - isn't this great?
I just want to give a real-world case where the current behaviour helped me to detect an infinite recursion early.
I wrote the following code, that implements a `poke` fo...This is a ticket you have nothing to do about - isn't this great?
I just want to give a real-world case where the current behaviour helped me to detect an infinite recursion early.
I wrote the following code, that implements a `poke` for any `Traversable` container with `Storable` elements:
```
poke ::
(Fold.Foldable f, Storable a) =>
Ptr (f a) -> f a -> IO ()
poke ptr x =
evalStateT (Fold.traverse_ pokeState x) $
castPtr ptr
pokeState ::
(Storable a) =>
a -> StateT (Ptr a) IO ()
pokeState x = do
liftIO . flip poke x =<< get
modify (flip advancePtr 1)
```
You can find this code here:
> http://code.haskell.org/\~thielema/storable-record/src/Foreign/Storable/Traversable.hs
When I compiled this I got the compiler error:
```
src/Foreign/Storable/Traversable.hs:67:0:
Contexts differ in length
(Use -XRelaxedPolyRec to allow this)
When matching the contexts of the signatures for
poke :: forall (f :: * -> *) a.
(Fold.Foldable f, Storable a) =>
Ptr (f a) -> f a -> IO ()
pokeState :: forall a. (Storable a) => a -> StateT (Ptr a) IO ()
The signature contexts in a mutually recursive group should all be identical
When generalising the type(s) for poke, pokeState
```
This quickly pointed me to the problem, that the call to `poke` in `pokeState` actually was wrong. It must be `Storable.poke`. If GHC had compiled this, it would have certainly gone into an infinite recursion.
There are two ways to treat this example:
- Blame my naming style where I re-use common identifiers and distinguish them later by qualification.
- Count it as vote for keeping the RelaxedPolyRec as optional feature.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------- |
| Version | 6.12.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ghc@henning-thielemann.de |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"keeping RelaxedPolyRec as optional feature can help spotting infinite recursion","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ghc@henning-thielemann.de"],"type":"Bug","description":"This is a ticket you have nothing to do about - isn't this great?\r\nI just want to give a real-world case where the current behaviour helped me to detect an infinite recursion early.\r\n\r\nI wrote the following code, that implements a {{{poke}}} for any {{{Traversable}}} container with {{{Storable}}} elements:\r\n{{{\r\n poke ::\r\n (Fold.Foldable f, Storable a) =>\r\n Ptr (f a) -> f a -> IO ()\r\n poke ptr x =\r\n evalStateT (Fold.traverse_ pokeState x) $\r\n castPtr ptr\r\n\r\n pokeState ::\r\n (Storable a) =>\r\n a -> StateT (Ptr a) IO ()\r\n pokeState x = do\r\n liftIO . flip poke x =<< get\r\n modify (flip advancePtr 1)\r\n}}}\r\n\r\nYou can find this code here:\r\n http://code.haskell.org/~thielema/storable-record/src/Foreign/Storable/Traversable.hs\r\n\r\nWhen I compiled this I got the compiler error:\r\n{{{\r\n src/Foreign/Storable/Traversable.hs:67:0:\r\n Contexts differ in length\r\n (Use -XRelaxedPolyRec to allow this)\r\n When matching the contexts of the signatures for\r\n poke :: forall (f :: * -> *) a.\r\n (Fold.Foldable f, Storable a) =>\r\n Ptr (f a) -> f a -> IO ()\r\n pokeState :: forall a. (Storable a) => a -> StateT (Ptr a) IO ()\r\n The signature contexts in a mutually recursive group should all be identical\r\n When generalising the type(s) for poke, pokeState\r\n}}}\r\nThis quickly pointed me to the problem, that the call to {{{poke}}} in {{{pokeState}}} actually was wrong. It must be {{{Storable.poke}}}. If GHC had compiled this, it would have certainly gone into an infinite recursion.\r\n\r\nThere are two ways to treat this example:\r\n* Blame my naming style where I re-use common identifiers and distinguish them later by qualification.\r\n* Count it as vote for keeping the RelaxedPolyRec as optional feature.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3820Pragma for suppressing 'orphan instance' warnings per instance2019-07-07T19:02:00ZguestPragma for suppressing 'orphan instance' warnings per instanceAdditionally to #2515 I'd like to suppress orphan instances warnings individually. I do not always like to disable orphan instance warnings globally for a module, since some of the warnings may point to an instance that can actually be m...Additionally to #2515 I'd like to suppress orphan instances warnings individually. I do not always like to disable orphan instance warnings globally for a module, since some of the warnings may point to an instance that can actually be moved to a more appropriate module.
Syntax could be
```
{-# NOWARN orphan #-}
instance C T where
...
```
or simply
```
{-# NOWARN #-}
instance C T where
...
```
(Before GHC-6.12 a general local NOWARN pragma could also help to minimize wrong warnings about unused imported modules. And sometimes I also like to disable 'unused identifier' warning for some top-level functions, that shall be type checked, but not exported, because their API is still not mature.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------- |
| Version | 6.12.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ghc@henning-thielemann.de |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Pragma for suppressing 'orphan instance' warnings per instance","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ghc@henning-thielemann.de"],"type":"FeatureRequest","description":"Additionally to #2515 I'd like to suppress orphan instances warnings individually. I do not always like to disable orphan instance warnings globally for a module, since some of the warnings may point to an instance that can actually be moved to a more appropriate module.\r\n\r\nSyntax could be\r\n{{{\r\n{-# NOWARN orphan #-}\r\ninstance C T where\r\n ...\r\n}}}\r\nor simply\r\n{{{\r\n{-# NOWARN #-}\r\ninstance C T where\r\n ...\r\n}}}\r\n\r\n(Before GHC-6.12 a general local NOWARN pragma could also help to minimize wrong warnings about unused imported modules. And sometimes I also like to disable 'unused identifier' warning for some top-level functions, that shall be type checked, but not exported, because their API is still not mature.)\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3826Can't infer type (type family as "element" type)2019-07-07T19:01:58ZsplCan't infer type (type family as "element" type)Suppose I have a class C,
```
class C a where
type E a
c :: E a -> a -> a
```
a datatype T,
```
data T a = T a
```
and an instance of C for T
```
instance C (T a) where
type E (T a) = a
c x (T _) = T x
```
I would like to w...Suppose I have a class C,
```
class C a where
type E a
c :: E a -> a -> a
```
a datatype T,
```
data T a = T a
```
and an instance of C for T
```
instance C (T a) where
type E (T a) = a
c x (T _) = T x
```
I would like to write a function such as f
```
f t@(T x) = c x t
```
without a type signature. Unfortunately, I can't because GHC tells me
```
Couldn't match expected type `t' against inferred type `T (E t)'
In the second argument of `c', namely `t'
In the expression: c x t
In the definition of `f': f (t@(T x)) = c x t
```
There are at least three possible ways to write the above code such
that it works.
(1) Give a type signature for f
```
f :: T a -> T a
```
(2) Define the class C using an equality constraint
```
class C t where
type E t
c :: (E t ~ e) => e -> t -> t
```
(3) Define the class C using functional dependencies
```
class C t e | t -> e where
c :: e -> t -> t
```
But the real question is why don't I get a type for f?
This has been tested in GHC 6.10.1 and 6.12.1.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | leather@cs.uu.nl |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Can't infer type (type family as \"element\" type)","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":["families","type"],"differentials":[],"test_case":"","architecture":"","cc":["leather@cs.uu.nl"],"type":"Bug","description":"Suppose I have a class C,\r\n\r\n{{{\r\nclass C a where\r\n type E a\r\n c :: E a -> a -> a\r\n}}}\r\n\r\na datatype T,\r\n\r\n{{{\r\ndata T a = T a\r\n}}}\r\n\r\nand an instance of C for T\r\n\r\n{{{\r\ninstance C (T a) where\r\n type E (T a) = a\r\n c x (T _) = T x\r\n}}}\r\n\r\nI would like to write a function such as f\r\n\r\n{{{\r\nf t@(T x) = c x t\r\n}}}\r\n\r\nwithout a type signature. Unfortunately, I can't because GHC tells me\r\n\r\n{{{\r\n Couldn't match expected type `t' against inferred type `T (E t)'\r\n In the second argument of `c', namely `t'\r\n In the expression: c x t\r\n In the definition of `f': f (t@(T x)) = c x t\r\n}}}\r\n\r\nThere are at least three possible ways to write the above code such\r\nthat it works.\r\n\r\n(1) Give a type signature for f\r\n\r\n{{{\r\nf :: T a -> T a\r\n}}}\r\n\r\n(2) Define the class C using an equality constraint\r\n\r\n{{{\r\nclass C t where\r\n type E t\r\n c :: (E t ~ e) => e -> t -> t\r\n}}}\r\n\r\n(3) Define the class C using functional dependencies\r\n\r\n{{{\r\nclass C t e | t -> e where\r\n c :: e -> t -> t\r\n}}}\r\n\r\nBut the real question is why don't I get a type for f?\r\n\r\nThis has been tested in GHC 6.10.1 and 6.12.1.","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/3851type family does not get expanded in ghc-6.12.12019-07-07T19:01:51ZAndres Löhtype family does not get expanded in ghc-6.12.1The following code (which is a trimmed down version of an application of the multirec library) does not compile on ghc-6.12.1,
but it does with ghc-6.10.4. Why?
```
{-# LANGUAGE GADTs, TypeFamilies #-}
type family TF a :: * -> *
type in...The following code (which is a trimmed down version of an application of the multirec library) does not compile on ghc-6.12.1,
but it does with ghc-6.10.4. Why?
```
{-# LANGUAGE GADTs, TypeFamilies #-}
type family TF a :: * -> *
type instance TF () = App (Equ ())
data Equ ix ix' where Refl :: Equ ix ix
data App f x = App (f x)
-- does not typecheck in 6.12.1 (but works in 6.10.4)
bar :: TF () () -> ()
bar (App Refl) = ()
-- does typecheck in 6.12.1 and 6.10.4
ar :: App (Equ ()) () -> ()
ar (App Refl) = ()
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------------------------------- |
| Version | 6.12.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | andres@cs.uu.nl, jpm@cs.uu.nl, stefan@cs.uu.nl |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"type family does not get expanded in ghc-6.12.1","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["andres@cs.uu.nl","jpm@cs.uu.nl","stefan@cs.uu.nl"],"type":"Bug","description":"The following code (which is a trimmed down version of an application of the multirec library) does not compile on ghc-6.12.1,\r\nbut it does with ghc-6.10.4. Why?\r\n\r\n{{{\r\n{-# LANGUAGE GADTs, TypeFamilies #-}\r\ntype family TF a :: * -> *\r\ntype instance TF () = App (Equ ())\r\n\r\ndata Equ ix ix' where Refl :: Equ ix ix\r\ndata App f x = App (f x)\r\n\r\n-- does not typecheck in 6.12.1 (but works in 6.10.4)\r\nbar :: TF () () -> ()\r\nbar (App Refl) = ()\r\n\r\n-- does typecheck in 6.12.1 and 6.10.4\r\nar :: App (Equ ()) () -> ()\r\nar (App Refl) = ()\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3877Require XOverlappingInstances for the most specific instance only2019-07-07T19:01:43Ztraz161616Require XOverlappingInstances for the most specific instance onlyI tried compiling the attached snippet with both ghc 6.12.1 and 6.10.4. The result is that even with XOverlappingInstances flag it still does not allow the program although it is provided with a concrete instance.
The code snippet is:
...I tried compiling the attached snippet with both ghc 6.12.1 and 6.10.4. The result is that even with XOverlappingInstances flag it still does not allow the program although it is provided with a concrete instance.
The code snippet is:
```
{- File overlap.hs -}
{-# OPTIONS_GHC -XOverlappingInstances -XTypeSynonymInstances #-}
type PairIS = (Int,String)
instance Show PairIS where
show (a,b) = "(("++(show a)++","++(show b)++"))"
test :: Int -> String -> String
test a b = show (a,b)
```
The OS is :Linux 2.6.31-19-server #56-Ubuntu SMP x86_64
The gcc version is (irrelevant): gcc version 4.4.1
The error message is:
```
Glasgow Haskell Compiler, Version 6.12.1, for Haskell 98, stage 2 booted by GHC version 6.8.2
Using binary package database: /usr/local/lib/ghc-6.12.1/package.conf.d/package.cache
wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-9d35c97e886f807a1e6d024aaa91dcec
wired-in package integer-gmp mapped to integer-gmp-0.2.0.0-9a51ffb34a83618a1a3d4e472b9977a0
wired-in package base mapped to base-4.2.0.0-b340bbd470b5859bcbb920aea62a12cf
wired-in package rts mapped to builtin_rts
wired-in package haskell98 mapped to haskell98-1.0.1.1-0fdaf3b26bc38c43ce8371edf538dbf6
wired-in package template-haskell mapped to template-haskell-2.4.0.0-fc13d9708caa0cfdc4173ee31dc2bf26
wired-in package dph-seq mapped to dph-seq-0.4.0-b8a71915f9569cbd3a6895da8311707a
wired-in package dph-par mapped to dph-par-0.4.0-68df56bb8ae18f20e3518a7b338d7ebc
Hsc static flags: -static
D:\code\overlap.hs:8:11:
Overlapping instances for Show (Int, String)
arising from a use of `show' at D:\code\overlap.hs:8:11-20
Matching instances:
instance (Show a, Show b) => Show (a, b) -- Defined in GHC.Show
instance [overlap ok] Show PairIS
-- Defined at D:\code\overlap.hs:4:9-19
In the expression: show (a, b)
In the definition of `test': test a b = show (a, b)
```7.2.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3902Partial application gives type error2019-07-07T19:01:36ZmoleculeColonyPartial application gives type errorI've tried to use the following line in my code (just to save some typing):
fI = fromIntegral
However, in certain cases it gives a type error, whereas the following version works:
fI x = fromIntegral x
Here a program that doesn't com...I've tried to use the following line in my code (just to save some typing):
fI = fromIntegral
However, in certain cases it gives a type error, whereas the following version works:
fI x = fromIntegral x
Here a program that doesn't compile (with the error at the end):
```
import Graphics.UI.Gtk
import Graphics.UI.Gtk.Gdk.EventM
import Control.Monad.Reader
import System.Random
import Data.Array.MArray
import Data.Array.IO
import Data.Word
main = do
parr <- newArray ((1,1,1),(600,600,3)) 127 :: IO (IOUArray (Int,Int,Int) Word8)
initGUI
win <- windowNew
brush <- pixbufNew ColorspaceRgb False 8 10 10
widgetShowAll win
dw <- widgetGetDrawWindow win
gc <- gcNew dw
timeoutAdd (draw parr dw gc brush) 1
on win deleteEvent $ tryEvent $ liftIO mainQuit
mainGUI
draw parr dw gc brush = do
x <- randomRIO (1,600)
y <- randomRIO (1,600)
rr <- randomRIO (0,255) :: IO Int
gr <- randomRIO (0,255) :: IO Int
br <- randomRIO (0,255) :: IO Int
rw <- readArray parr (x,y,1)
gw <- readArray parr (x,y,2)
bw <- readArray parr (x,y,3)
let (ro,go,bo) = (fI rw, fI gw, fI bw)
let cs = ro+go+bo
let rn = div cs 6 + div rr 2
let gn = div cs 6 + div gr 2
let bn = div cs 6 + div br 2
let (ra,ga,ba) = (fI rn,fI gn,fI bn)
writeArray parr (x,y,1) ra
writeArray parr (x,y,2) ga
writeArray parr (x,y,3) ba
pixbufFill brush ra ga ba 0
w <- randomRIO (1,10)
h <- randomRIO (1,10)
drawPixbuf dw gc brush 0 0 x y w h RgbDitherNone 0 0
return True
fI = fromIntegral
fitest.hs:39:19:
Couldn't match expected type `Word8' against inferred type `Int'
In the second argument of `pixbufFill', namely `ra'
In a stmt of a 'do' expression: pixbufFill brush ra ga ba 0
In the expression:
do x <- randomRIO (1, 600)
y <- randomRIO (1, 600)
rr <- randomRIO (0, 255) :: IO Int
gr <- randomRIO (0, 255) :: IO Int
....
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.4 |
| 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":"Partial application gives type error","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've tried to use the following line in my code (just to save some typing):\r\n\r\nfI = fromIntegral\r\n\r\nHowever, in certain cases it gives a type error, whereas the following version works:\r\n\r\nfI x = fromIntegral x\r\n\r\nHere a program that doesn't compile (with the error at the end):\r\n\r\n{{{\r\nimport Graphics.UI.Gtk\r\nimport Graphics.UI.Gtk.Gdk.EventM\r\nimport Control.Monad.Reader\r\nimport System.Random\r\nimport Data.Array.MArray\r\nimport Data.Array.IO\r\nimport Data.Word\r\n\r\nmain = do\r\n parr <- newArray ((1,1,1),(600,600,3)) 127 :: IO (IOUArray (Int,Int,Int) Word8)\r\n initGUI\r\n win <- windowNew\r\n brush <- pixbufNew ColorspaceRgb False 8 10 10\r\n widgetShowAll win\r\n dw <- widgetGetDrawWindow win\r\n gc <- gcNew dw\r\n timeoutAdd (draw parr dw gc brush) 1\r\n on win deleteEvent $ tryEvent $ liftIO mainQuit\r\n mainGUI\r\n\r\ndraw parr dw gc brush = do\r\n x <- randomRIO (1,600)\r\n y <- randomRIO (1,600)\r\n rr <- randomRIO (0,255) :: IO Int\r\n gr <- randomRIO (0,255) :: IO Int\r\n br <- randomRIO (0,255) :: IO Int\r\n rw <- readArray parr (x,y,1)\r\n gw <- readArray parr (x,y,2)\r\n bw <- readArray parr (x,y,3)\r\n let (ro,go,bo) = (fI rw, fI gw, fI bw)\r\n let cs = ro+go+bo\r\n let rn = div cs 6 + div rr 2\r\n let gn = div cs 6 + div gr 2\r\n let bn = div cs 6 + div br 2\r\n let (ra,ga,ba) = (fI rn,fI gn,fI bn)\r\n writeArray parr (x,y,1) ra\r\n writeArray parr (x,y,2) ga\r\n writeArray parr (x,y,3) ba\r\n pixbufFill brush ra ga ba 0\r\n w <- randomRIO (1,10)\r\n h <- randomRIO (1,10)\r\n drawPixbuf dw gc brush 0 0 x y w h RgbDitherNone 0 0\r\n return True\r\n\r\nfI = fromIntegral\r\n\r\n\r\n\r\n\r\nfitest.hs:39:19:\r\n Couldn't match expected type `Word8' against inferred type `Int'\r\n In the second argument of `pixbufFill', namely `ra'\r\n In a stmt of a 'do' expression: pixbufFill brush ra ga ba 0\r\n In the expression:\r\n do x <- randomRIO (1, 600)\r\n y <- randomRIO (1, 600)\r\n rr <- randomRIO (0, 255) :: IO Int\r\n gr <- randomRIO (0, 255) :: IO Int\r\n ....\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3950panic: Unify.uTys_s: mismatched type lists!2019-07-07T19:01:23Zganeshpanic: Unify.uTys_s: mismatched type lists!This erroneous program provokes a panic instead of a type error, with GHC 6.8.3, 6.10.4 and 6.12.1. I don't have any recent snapshots to hand to try.
```
{-# LANGUAGE GADTs #-}
data Id p x y = Id (p x y)
data Sealed p where
Sealed ...This erroneous program provokes a panic instead of a type error, with GHC 6.8.3, 6.10.4 and 6.12.1. I don't have any recent snapshots to hand to try.
```
{-# LANGUAGE GADTs #-}
data Id p x y = Id (p x y)
data Sealed p where
Sealed :: p x -> Sealed p
rp :: Bool -> Maybe (w (Id p))
rp _ = Just rp'
where rp' :: Sealed (Id p x)
rp' = undefined
```
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.12.1 for x86_64-unknown-linux):
Unify.uTys_s: mismatched type lists!
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.8.3 |
| 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":"panic: Unify.uTys_s: mismatched type lists!","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This erroneous program provokes a panic instead of a type error, with GHC 6.8.3, 6.10.4 and 6.12.1. I don't have any recent snapshots to hand to try.\r\n{{{\r\n{-# LANGUAGE GADTs #-}\r\n\r\ndata Id p x y = Id (p x y)\r\n\r\ndata Sealed p where\r\n Sealed :: p x -> Sealed p\r\n\r\nrp :: Bool -> Maybe (w (Id p))\r\nrp _ = Just rp'\r\n where rp' :: Sealed (Id p x)\r\n rp' = undefined\r\n}}}\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.12.1 for x86_64-unknown-linux):\r\n Unify.uTys_s: mismatched type lists!\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3954Contexts on empty data decls falsely rejected2019-07-07T19:01:22ZksfContexts on empty data decls falsely rejectedHList uses EmptyDataDecls and contains
```
data HNat x => Label x ns desc
```
which fails with
```
Data/HList/Label3.hs:37:0:
No context is allowed on a GADT-style data declaration
(You can put a context on each contructor, t...HList uses EmptyDataDecls and contains
```
data HNat x => Label x ns desc
```
which fails with
```
Data/HList/Label3.hs:37:0:
No context is allowed on a GADT-style data declaration
(You can put a context on each contructor, though.)
```
, regressing from 6.10.
My crystal ball tells me someone has been simplifying the implementation of EmptyDataDecls to be GADTs without `where`, and missed the corner case.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.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":"Contexts on empty data decls falsely rejected","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"HList uses EmptyDataDecls and contains\r\n\r\n{{{\r\ndata HNat x => Label x ns desc \r\n}}}\r\n\r\nwhich fails with \r\n\r\n{{{ \r\nData/HList/Label3.hs:37:0:\r\n No context is allowed on a GADT-style data declaration\r\n (You can put a context on each contructor, though.) \r\n}}}\r\n\r\n, regressing from 6.10.\r\n\r\nMy crystal ball tells me someone has been simplifying the implementation of EmptyDataDecls to be GADTs without {{{where}}}, and missed the corner case.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3958method definitions fail to refer to method-context classes2019-07-07T19:01:21Zvisionetemethod definitions fail to refer to method-context classesSorry in advance if this is my lack of understanding...\[\[BR\]\]
The following code fails:\[\[BR\]\]
```
class Cfoo a where
f :: Int -> a -> Int
data Foo = F Int
instance Cfoo Foo where
f m (F n) = m + n
data Bar = B Int
cl...Sorry in advance if this is my lack of understanding...\[\[BR\]\]
The following code fails:\[\[BR\]\]
```
class Cfoo a where
f :: Int -> a -> Int
data Foo = F Int
instance Cfoo Foo where
f m (F n) = m + n
data Bar = B Int
class Cbar a where
g :: (Cfoo b) => a -> b
instance Cbar Bar where
g (B m) = F m
```
with error:\[\[BR\]\]
```
Couldn't match expected type `b' against inferred type `Foo'
`b' is a rigid type variable bound by
the type signature for `g' at [...]
In the expression: F m
In the definition of `g': g (B m) = F m
In the instance declaration for `Cbar Bar'
```
It's as if the "instance Cfoo Foo" statement is ignored when processing "instance CBar Bar"
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.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":"method definitions fail to refer to method-context classes","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Sorry in advance if this is my lack of understanding...[[BR]]\r\nThe following code fails:[[BR]]\r\n\r\n{{{\r\nclass Cfoo a where\r\n f :: Int -> a -> Int\r\n\r\ndata Foo = F Int\r\n\r\ninstance Cfoo Foo where\r\n f m (F n) = m + n\r\n\r\ndata Bar = B Int\r\n\r\nclass Cbar a where\r\n g :: (Cfoo b) => a -> b\r\n\r\ninstance Cbar Bar where\r\n g (B m) = F m\r\n}}}\r\n\r\n\r\nwith error:[[BR]]\r\n{{{\r\nCouldn't match expected type `b' against inferred type `Foo'\r\n `b' is a rigid type variable bound by\r\n the type signature for `g' at [...]\r\n In the expression: F m\r\n In the definition of `g': g (B m) = F m\r\n In the instance declaration for `Cbar Bar'\r\n}}}\r\nIt's as if the \"instance Cfoo Foo\" statement is ignored when processing \"instance CBar Bar\"","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4008type error trying to specialize polymorphic function2019-07-07T19:01:08Znr@eecs.harvard.edutype error trying to specialize polymorphic functionThe attached module won't compile---definition of 'wrap'
is rejected. The error message is
```
[ 1 of 13] Compiling Pain ( Pain.hs, Pain.o )
Pain.hs:18:7:
Couldn't match expected type `n C O' against inferred type `C'
...The attached module won't compile---definition of 'wrap'
is rejected. The error message is
```
[ 1 of 13] Compiling Pain ( Pain.hs, Pain.o )
Pain.hs:18:7:
Couldn't match expected type `n C O' against inferred type `C'
Expected type: ExTriple (Counter n)
Inferred type: ExTriple (->)
In the expression: scalar
In the definition of `wrap': wrap = scalar
```
The inferred type is alarming, and in any case the type of wrap is
a straightforward specialization of the type of scalar.
Could the problem be with liberal type synonyms?
I don't think we're doing anything unreasonable...
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | dias@cs.tufts.edu |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"type error trying to specialize polymorphic function","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["dias@cs.tufts.edu"],"type":"Bug","description":"The attached module won't compile---definition of 'wrap' \r\nis rejected. The error message is\r\n{{{\r\n[ 1 of 13] Compiling Pain ( Pain.hs, Pain.o )\r\n\r\nPain.hs:18:7:\r\n Couldn't match expected type `n C O' against inferred type `C'\r\n Expected type: ExTriple (Counter n)\r\n Inferred type: ExTriple (->)\r\n In the expression: scalar\r\n In the definition of `wrap': wrap = scalar\r\n}}}\r\nThe inferred type is alarming, and in any case the type of wrap is \r\na straightforward specialization of the type of scalar.\r\n\r\nCould the problem be with liberal type synonyms?\r\nI don't think we're doing anything unreasonable...\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/4009can newtype be extended to permit GADT-like declarations2021-01-06T16:06:47Znr@eecs.harvard.educan newtype be extended to permit GADT-like declarationsI'd like to create the following value constructor without the overhead of `data`:
```
data B n e x where
B :: Body n -> B n C C
```
However, if I ask for `newtype` instead of `data` I'm told that a newtype constructor must have a re...I'd like to create the following value constructor without the overhead of `data`:
```
data B n e x where
B :: Body n -> B n C C
```
However, if I ask for `newtype` instead of `data` I'm told that a newtype constructor must have a return type of form `T a1 ... an`. Is this restriction fundamental? If not, could it be possible to allow GADT-like declarations for `newtype`?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.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":"can newtype be extended to permit GADT-like declarations","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":["GADT","newtype"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I'd like to create the following value constructor without the overhead of {{{data}}}:\r\n{{{\r\ndata B n e x where\r\n B :: Body n -> B n C C\r\n}}}\r\nHowever, if I ask for {{{newtype}}} instead of {{{data}}} I'm told that a newtype constructor must have a return type of form {{{T a1 ... an}}}. Is this restriction fundamental? If not, could it be possible to allow GADT-like declarations for {{{newtype}}}?\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/4028Derived Data instance requires Data instances for unused type parameters2019-07-07T19:01:02ZIan Lynagh <igloo@earth.li>Derived Data instance requires Data instances for unused type parametersFirst reported here: http://www.haskell.org/pipermail/glasgow-haskell-users/2010-April/018785.html
With this module:
```
{-# LANGUAGE DeriveDataTypeable #-}
import Data.Data
import Data.Typeable
newtype FSVec s a = FSVec {unFSVec :: ...First reported here: http://www.haskell.org/pipermail/glasgow-haskell-users/2010-April/018785.html
With this module:
```
{-# LANGUAGE DeriveDataTypeable #-}
import Data.Data
import Data.Typeable
newtype FSVec s a = FSVec {unFSVec :: [a]}
deriving (Eq, Typeable, Data)
```
1. 12 now has a `Data s` requirement on the `Data (FSVec s a)` instance.
With 6.10.4:
```
*Main> :i FSVec
newtype FSVec s a = FSVec {unFSVec :: [a]}
-- Defined at q.hs:7:8-12
instance (Eq a) => Eq (FSVec s a) -- Defined at q.hs:8:14-15
instance (Data a, Typeable s) => Data (FSVec s a)
-- Defined at q.hs:8:28-31
instance Typeable2 FSVec -- Defined at q.hs:8:18-25
```
With 6.12 (and the HEAD):
```
*Main> :i FSVec
newtype FSVec s a = FSVec {unFSVec :: [a]}
-- Defined at q.hs:7:8-12
instance (Eq a) => Eq (FSVec s a) -- Defined at q.hs:8:14-15
instance (Data s, Data a) => Data (FSVec s a)
-- Defined at q.hs:8:28-31
instance Typeable2 FSVec -- Defined at q.hs:8:18-25
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.2 |
| 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":"Derived Data instance requires Data instances for unused type parameters","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"6.14.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"First reported here: http://www.haskell.org/pipermail/glasgow-haskell-users/2010-April/018785.html\r\n\r\nWith this module:\r\n{{{\r\n{-# LANGUAGE DeriveDataTypeable #-}\r\n\r\nimport Data.Data\r\nimport Data.Typeable\r\n\r\nnewtype FSVec s a = FSVec {unFSVec :: [a]}\r\n deriving (Eq, Typeable, Data)\r\n}}}\r\n6.12 now has a `Data s` requirement on the `Data (FSVec s a)` instance.\r\n\r\nWith 6.10.4:\r\n{{{\r\n*Main> :i FSVec\r\nnewtype FSVec s a = FSVec {unFSVec :: [a]}\r\n -- Defined at q.hs:7:8-12\r\ninstance (Eq a) => Eq (FSVec s a) -- Defined at q.hs:8:14-15\r\ninstance (Data a, Typeable s) => Data (FSVec s a)\r\n -- Defined at q.hs:8:28-31\r\ninstance Typeable2 FSVec -- Defined at q.hs:8:18-25\r\n}}}\r\nWith 6.12 (and the HEAD):\r\n{{{\r\n*Main> :i FSVec\r\nnewtype FSVec s a = FSVec {unFSVec :: [a]}\r\n -- Defined at q.hs:7:8-12\r\ninstance (Eq a) => Eq (FSVec s a) -- Defined at q.hs:8:14-15\r\ninstance (Data s, Data a) => Data (FSVec s a)\r\n -- Defined at q.hs:8:28-31\r\ninstance Typeable2 FSVec -- Defined at q.hs:8:18-25\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/4120Iface type variable out of scope in cast2019-07-07T19:00:29ZbenlIface type variable out of scope in castCompiling the following module against vector-0.6 or 0.7:
```
module Thing where
import Data.Vector.Unboxed
import Data.Vector.Unboxed.Mutable as MV
thing :: Vector Int
thing = create (MV.new 5)
```
Complains about:
```
desire:tmp be...Compiling the following module against vector-0.6 or 0.7:
```
module Thing where
import Data.Vector.Unboxed
import Data.Vector.Unboxed.Mutable as MV
thing :: Vector Int
thing = create (MV.new 5)
```
Complains about:
```
desire:tmp benl$ ghc -O -c -fglasgow-exts Thing.hs -fforce-recomp
/Users/benl/.cabal/lib/vector-0.7/ghc-6.13.20100607/Data/Vector/Unboxed.hi
Declaration for create
Unfolding of Data.Vector.Unboxed.create:
Iface type variable out of scope: s
```
Looking in the interface file we have:
```
create :: forall a.
Data.Vector.Unboxed.Base.Unbox a =>
(forall s. GHC.ST.ST s (Data.Vector.Unboxed.Base.MVector s a))
-> Data.Vector.Unboxed.Base.Vector a
{- Arity: 2, Strictness: U(SA)C(U(LL)),
Inline: INLINE (sat-args=0),
Unfolding: InlineRule (1, False, False)
(\ @ a
$dUnbox :: Data.Vector.Unboxed.Base.Unbox a
eta :: forall s.
GHC.ST.ST
s
(Data.Vector.Generic.Base.Mutable
Data.Vector.Unboxed.Base.Vector s a) ->
Data.Vector.Generic.new
@ Data.Vector.Unboxed.Base.Vector
@ a
(Data.Vector.Unboxed.Base.$p1Unbox @ a $dUnbox)
(Data.Vector.Generic.New.New
@ Data.Vector.Unboxed.Base.Vector
@ a
eta))
`cast`
(forall a.
Data.Vector.Unboxed.Base.Unbox a =>
GHC.ST.ST s (Data.Vector.Unboxed.Base.TFCo:R:MutableVector s a)
-> Data.Vector.Unboxed.Base.Vector a) -}
```
The variable `s` in the right of the cast is indeed not in scope.
This prevents `create` being inlined into client modules, which kills performance for benchmarks that create lots of small vectors (like a version of quickhull in DPH).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.13 |
| 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":"Iface type variable out of scope in cast","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compiling the following module against vector-0.6 or 0.7:\r\n\r\n{{{\r\nmodule Thing where\r\nimport Data.Vector.Unboxed\r\nimport Data.Vector.Unboxed.Mutable\tas MV\r\n\r\nthing :: Vector Int\r\nthing = create (MV.new 5)\r\n}}}\r\n\r\nComplains about:\r\n{{{\r\ndesire:tmp benl$ ghc -O -c -fglasgow-exts Thing.hs -fforce-recomp\r\n/Users/benl/.cabal/lib/vector-0.7/ghc-6.13.20100607/Data/Vector/Unboxed.hi\r\nDeclaration for create\r\nUnfolding of Data.Vector.Unboxed.create:\r\n Iface type variable out of scope: s\r\n}}}\r\n\r\nLooking in the interface file we have:\r\n{{{\r\n create :: forall a.\r\n Data.Vector.Unboxed.Base.Unbox a =>\r\n (forall s. GHC.ST.ST s (Data.Vector.Unboxed.Base.MVector s a))\r\n -> Data.Vector.Unboxed.Base.Vector a\r\n {- Arity: 2, Strictness: U(SA)C(U(LL)),\r\n Inline: INLINE (sat-args=0),\r\n Unfolding: InlineRule (1, False, False)\r\n (\\ @ a\r\n $dUnbox :: Data.Vector.Unboxed.Base.Unbox a\r\n eta :: forall s.\r\n GHC.ST.ST\r\n s\r\n (Data.Vector.Generic.Base.Mutable\r\n Data.Vector.Unboxed.Base.Vector s a) ->\r\n Data.Vector.Generic.new\r\n @ Data.Vector.Unboxed.Base.Vector\r\n @ a\r\n (Data.Vector.Unboxed.Base.$p1Unbox @ a $dUnbox)\r\n (Data.Vector.Generic.New.New\r\n @ Data.Vector.Unboxed.Base.Vector\r\n @ a\r\n eta))\r\n `cast`\r\n (forall a.\r\n Data.Vector.Unboxed.Base.Unbox a =>\r\n GHC.ST.ST s (Data.Vector.Unboxed.Base.TFCo:R:MutableVector s a)\r\n -> Data.Vector.Unboxed.Base.Vector a) -}\r\n}}}\r\n\r\nThe variable `s` in the right of the cast is indeed not in scope.\r\n\r\nThis prevents `create` being inlined into client modules, which kills performance for benchmarks that create lots of small vectors (like a version of quickhull in DPH).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4174Jumbled error message from type family operator2019-07-07T19:00:15ZlilacJumbled error message from type family operatorThe attached file produces this error message:
```
Testcase.hs:82:0:
Couldn't match expected type `True'
against inferred type `Main.R::<=:GHC6'10GHC6'8 Minor1 minor'
When generalising the type(s) for `testcase'
```
...The attached file produces this error message:
```
Testcase.hs:82:0:
Couldn't match expected type `True'
against inferred type `Main.R::<=:GHC6'10GHC6'8 Minor1 minor'
When generalising the type(s) for `testcase'
```
That should say
```
[...] against inferred type `GHC6'10 Minor1 :<=: GHC6'8 minor'
```
Apologies for the complexity of the testcase; simpler testcases seem to not reproduce the problem.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.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":"Jumbled error message from type family operator","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached file produces this error message:\r\n\r\n{{{\r\nTestcase.hs:82:0:\r\n Couldn't match expected type `True'\r\n against inferred type `Main.R::<=:GHC6'10GHC6'8 Minor1 minor'\r\n When generalising the type(s) for `testcase'\r\n}}}\r\n\r\nThat should say\r\n{{{\r\n[...] against inferred type `GHC6'10 Minor1 :<=: GHC6'8 minor'\r\n}}}\r\n\r\nApologies for the complexity of the testcase; simpler testcases seem to not reproduce the problem.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4178Lazy evaluation of type families causes quantified type variables to escape2019-07-07T19:00:14ZintoverflowLazy evaluation of type families causes quantified type variables to escapeThis may be related to tickets #3005 and #3297.
Consider the following function, which is idiomatic for using rank-2 types to prevent data from escaping a context:
```
useRank2 :: (forall a . a -> b) -> b
useRank2 f = f "foo"
```
If `...This may be related to tickets #3005 and #3297.
Consider the following function, which is idiomatic for using rank-2 types to prevent data from escaping a context:
```
useRank2 :: (forall a . a -> b) -> b
useRank2 f = f "foo"
```
If `b` is unified to a type function that makes mention of `a`, the compiler will reject the program for allowing a quantified type variable to escape, even in circumstances where evaluating the type function would yield a type that does not mention `a`.
Here is complete source for demonstrating the issue:
```
{-# LANGUAGE
FlexibleContexts,
Rank2Types,
TypeFamilies,
MultiParamTypeClasses,
FlexibleInstances #-}
data True = T
data False = F
class Decide tf a b where
type If tf a b
nonFunctionalIf :: tf -> a -> b -> If tf a b
instance Decide True a b where
type If True a b = a
nonFunctionalIf T a b = a
instance Decide False a b where
type If False a b = b
nonFunctionalIf F a b = b
useRank2 :: (forall a . a -> b) -> b
useRank2 f = f "foo"
hasTrouble a = nonFunctionalIf F a (2 :: Int)
-- try useRank2 hasTrouble
hasNoTrouble :: a -> Int
hasNoTrouble = hasTrouble
-- try useRank2 hasNoTrouble
```
Certainly the program should be rejected when there is inadequate information to evaluate the type function, but it seems odd to reject `hasTrouble` and not `hasNoTrouble` given that they are equal.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"Lazy evaluation of type families causes quantified type variables to escape","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This may be related to tickets #3005 and #3297.\r\n\r\nConsider the following function, which is idiomatic for using rank-2 types to prevent data from escaping a context:\r\n\r\n{{{\r\nuseRank2 :: (forall a . a -> b) -> b\r\nuseRank2 f = f \"foo\"\r\n}}}\r\n\r\nIf {{{b}}} is unified to a type function that makes mention of {{{a}}}, the compiler will reject the program for allowing a quantified type variable to escape, even in circumstances where evaluating the type function would yield a type that does not mention {{{a}}}.\r\n\r\nHere is complete source for demonstrating the issue:\r\n\r\n{{{\r\n{-# LANGUAGE\r\n\tFlexibleContexts,\r\n\tRank2Types,\r\n\tTypeFamilies,\r\n\tMultiParamTypeClasses,\r\n\tFlexibleInstances #-}\r\n\r\ndata True = T\r\ndata False = F\r\n\r\nclass Decide tf a b where\r\n type If tf a b\r\n nonFunctionalIf :: tf -> a -> b -> If tf a b\r\n\r\ninstance Decide True a b where\r\n type If True a b = a\r\n nonFunctionalIf T a b = a\r\n\r\ninstance Decide False a b where\r\n type If False a b = b\r\n nonFunctionalIf F a b = b\r\n\r\nuseRank2 :: (forall a . a -> b) -> b\r\nuseRank2 f = f \"foo\"\r\n\r\nhasTrouble a = nonFunctionalIf F a (2 :: Int)\r\n-- try useRank2 hasTrouble\r\n\r\nhasNoTrouble :: a -> Int\r\nhasNoTrouble = hasTrouble\r\n-- try useRank2 hasNoTrouble\r\n}}}\r\n\r\nCertainly the program should be rejected when there is inadequate information to evaluate the type function, but it seems odd to reject {{{hasTrouble}}} and not {{{hasNoTrouble}}} given that they are equal.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4179Infinite loop with type function inference2019-07-07T19:00:14ZSimon Peyton JonesInfinite loop with type function inferenceKevin Quick (quick\@sparq.org) writes:
I started with the following:
```
{-# LANGUAGE TypeFamilies #-}
class DoC a where
type A2 a
op :: a -> A2 a
data Con x = InCon (x (Con x))
type FCon x = x (Con x)
foldDoC :: Functor f...Kevin Quick (quick\@sparq.org) writes:
I started with the following:
```
{-# LANGUAGE TypeFamilies #-}
class DoC a where
type A2 a
op :: a -> A2 a
data Con x = InCon (x (Con x))
type FCon x = x (Con x)
foldDoC :: Functor f => (f a -> a) -> Con f -> a foldDoC f (InCon t) = f (fmap (foldDoC f) t)
doCon :: (DoC (FCon x)) => Con x -> A2 (FCon x) doCon (InCon x) = op x
fCon :: (Functor x, DoC (FCon x)) => Con x -> A2 (FCon x) fCon = foldDoC op
```
I then changed the rank of op, but forgot to update the foldDoC accordingly---see below. Attempting to compile this causes GHC to run forever using 100% cpu. The corrected definition of foldDoC works fine. Should the GHC (6.12.1) behavior in the face of my foolishness be reported as a bug or is this a legitimate infinite recursion of type deduction?
```
{-# LANGUAGE TypeFamilies #-}
class DoC a where
type A2 a
type A3 a
op :: a -> A2 a -> A3 a
data Con x = InCon (x (Con x))
type FCon x = x (Con x)
-- should have been changed to this, which works
-- foldDoC :: Functor f => (f a -> a) -> A2 (FCon f) -> Con f -> a
-- foldDoC f i (InCon t) = f (fmap (foldDoC f i) t)
-- this original version causes GHC to hang foldDoC :: Functor f => (f a -> a) -> Con f -> a foldDoC f (InCon t) = f (fmap (foldDoC f) t)
doCon :: (DoC (FCon x)) => Con x -> A2 (FCon x) -> A3 (FCon x) doCon (InCon x) = op x
-- note that if this is commented out then there's no hang: presumably because GHC doesn't have to perform type deduction for foldDoC.
fCon :: (Functor x, DoC (FCon x)) => Con x -> A2 (FCon x) -> A3 (FCon x) fCon = foldDoC op
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.3 |
| 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":"Infinite loop with type function inference","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Kevin Quick (quick@sparq.org) writes:\r\nI started with the following:\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\nclass DoC a where\r\n type A2 a\r\n op :: a -> A2 a\r\n\r\ndata Con x = InCon (x (Con x))\r\ntype FCon x = x (Con x)\r\n\r\nfoldDoC :: Functor f => (f a -> a) -> Con f -> a foldDoC f (InCon t) = f (fmap (foldDoC f) t)\r\n\r\ndoCon :: (DoC (FCon x)) => Con x -> A2 (FCon x) doCon (InCon x) = op x\r\n\r\nfCon :: (Functor x, DoC (FCon x)) => Con x -> A2 (FCon x) fCon = foldDoC op\r\n}}}\r\nI then changed the rank of op, but forgot to update the foldDoC accordingly---see below. Attempting to compile this causes GHC to run forever using 100% cpu. The corrected definition of foldDoC works fine. Should the GHC (6.12.1) behavior in the face of my foolishness be reported as a bug or is this a legitimate infinite recursion of type deduction?\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\nclass DoC a where\r\n type A2 a\r\n type A3 a\r\n op :: a -> A2 a -> A3 a\r\n\r\ndata Con x = InCon (x (Con x))\r\ntype FCon x = x (Con x)\r\n\r\n-- should have been changed to this, which works\r\n-- foldDoC :: Functor f => (f a -> a) -> A2 (FCon f) -> Con f -> a\r\n-- foldDoC f i (InCon t) = f (fmap (foldDoC f i) t)\r\n\r\n-- this original version causes GHC to hang foldDoC :: Functor f => (f a -> a) -> Con f -> a foldDoC f (InCon t) = f (fmap (foldDoC f) t)\r\n\r\ndoCon :: (DoC (FCon x)) => Con x -> A2 (FCon x) -> A3 (FCon x) doCon (InCon x) = op x\r\n\r\n-- note that if this is commented out then there's no hang: presumably because GHC doesn't have to perform type deduction for foldDoC.\r\nfCon :: (Functor x, DoC (FCon x)) => Con x -> A2 (FCon x) -> A3 (FCon x) fCon = foldDoC op\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4226Lifting constraints is questionably correct for implicit parameters.2019-07-07T19:00:00ZdolioLifting constraints is questionably correct for implicit parameters.Greetings,
While fooling with implicit parameters today, I encountered an anomaly. Part of (I think) the justification of implicit parameters is that the types inform you of what they do. So, for instance:
```
(\() -> ?x) :: (?x :: Int...Greetings,
While fooling with implicit parameters today, I encountered an anomaly. Part of (I think) the justification of implicit parameters is that the types inform you of what they do. So, for instance:
```
(\() -> ?x) :: (?x :: Int) => () -> Int
```
depends on an implicit parameter, while:
```
(let ?x = 5 in \() -> ?x) :: () -> Int
```
does not. However, I discovered that the following:
```
(let ?x = 5 in \() -> ?x) :: () -> ((?x :: Int) => Int)
```
generates a function whose implicit parameter `?x` is actually unbound, so if we let that expression be `f`, then:
```
let ?x = 4 in f ()
```
yields 4. By contrast, if we give the type:
```
(let ?x = 5 in \() -> ?x) :: (?x :: Int) => () -> Int
```
the `?x` in the lambda expression *is* bound, and the implicit parameter constraint is spurious (like `5 :: (?x :: Int) => Int`). This happens for definitions in which types are given, so it does not seem like it is a case of the note on monomorphism in the implicit parameters documentation. For instance:
```
let f :: (?x :: Int) => () -> Int
f = let ?x = 5 in \() -> ?x
g :: () -> ((?x :: Int) => Int)
g = let ?x = 5 in \() -> ?x
in let ?x = 4
in (f (), g()) -- (5, 4)
```
This would arguably be fine, as the two have different types. However, GHC does not actually distinguish them. Asking the type of either will generate:
`(?x :: Int) => () -> Int`
Instead of the one with the higher-rank (so to speak) constraint.
I get this behavior using 6.12.1, but it seems unlikely that it would have changed in the 6.12 series.
Strictly speaking, I'm not sure I can call this a bug. Due to context weakening, there's probably no way to unambiguously clarify using types which values are genuinely dependent on implicit parameters, and which are not (similar to `ask` versus `local (const 5) ask` in `Reader`). However, it seems odd that the type annotations make a difference, yet are not subsequently distinguished. It's also conceivable that the `() -> ((?x :: Int) => Int)` behavior is unintentional. I am unsure which, if any, of these resolutions is appropriate.
So, instead, I'll call this a proposal, that we determine whether this is the intended behavior (feel free to promote to a bug if it is decided that something needs to be fixed, however). :)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.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":"Lifting constraints is questionably correct for implicit parameters.","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":["implicit","parameters"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Greetings,\r\n\r\nWhile fooling with implicit parameters today, I encountered an anomaly. Part of (I think) the justification of implicit parameters is that the types inform you of what they do. So, for instance:\r\n\r\n{{{\r\n(\\() -> ?x) :: (?x :: Int) => () -> Int\r\n}}}\r\n\r\ndepends on an implicit parameter, while:\r\n\r\n{{{\r\n(let ?x = 5 in \\() -> ?x) :: () -> Int\r\n}}}\r\n\r\ndoes not. However, I discovered that the following:\r\n\r\n{{{\r\n(let ?x = 5 in \\() -> ?x) :: () -> ((?x :: Int) => Int)\r\n}}}\r\n\r\ngenerates a function whose implicit parameter {{{?x}}} is actually unbound, so if we let that expression be {{{f}}}, then:\r\n\r\n{{{\r\nlet ?x = 4 in f ()\r\n}}}\r\n\r\nyields 4. By contrast, if we give the type:\r\n{{{\r\n(let ?x = 5 in \\() -> ?x) :: (?x :: Int) => () -> Int\r\n}}}\r\n\r\nthe {{{?x}}} in the lambda expression ''is'' bound, and the implicit parameter constraint is spurious (like {{{5 :: (?x :: Int) => Int}}}). This happens for definitions in which types are given, so it does not seem like it is a case of the note on monomorphism in the implicit parameters documentation. For instance:\r\n\r\n{{{\r\nlet f :: (?x :: Int) => () -> Int\r\n f = let ?x = 5 in \\() -> ?x\r\n g :: () -> ((?x :: Int) => Int)\r\n g = let ?x = 5 in \\() -> ?x\r\n in let ?x = 4\r\n in (f (), g()) -- (5, 4)\r\n}}}\r\n\r\nThis would arguably be fine, as the two have different types. However, GHC does not actually distinguish them. Asking the type of either will generate:\r\n\r\n{{{(?x :: Int) => () -> Int}}}\r\n\r\nInstead of the one with the higher-rank (so to speak) constraint.\r\n\r\nI get this behavior using 6.12.1, but it seems unlikely that it would have changed in the 6.12 series.\r\n\r\nStrictly speaking, I'm not sure I can call this a bug. Due to context weakening, there's probably no way to unambiguously clarify using types which values are genuinely dependent on implicit parameters, and which are not (similar to {{{ask}}} versus {{{local (const 5) ask}}} in {{{Reader}}}). However, it seems odd that the type annotations make a difference, yet are not subsequently distinguished. It's also conceivable that the {{{() -> ((?x :: Int) => Int)}}} behavior is unintentional. I am unsure which, if any, of these resolutions is appropriate.\r\n\r\nSo, instead, I'll call this a proposal, that we determine whether this is the intended behavior (feel free to promote to a bug if it is decided that something needs to be fixed, however). :)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4232Finish and merge new typechecker branch2019-07-07T18:59:56ZIan Lynagh <igloo@earth.li>Finish and merge new typechecker branchFinish and merge new typechecker branch
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.13 ...Finish and merge new typechecker branch
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.13 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Finish and merge new typechecker branch","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.0.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Finish and merge new typechecker branch","type_of_failure":"OtherFailure","blocking":[]} -->7.0.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/4235deriving Enum fails for data instances2019-07-07T18:59:55Znestraderiving Enum fails for data instancesThe following sample module does not compile:
```
{-# LANGUAGE TypeFamilies #-}
module Foo where
data family Foo a
data instance Foo Int
= A | B
deriving (Enum)
```
GHC gives 5 error messages, all to line 8 (the deriving clause),...The following sample module does not compile:
```
{-# LANGUAGE TypeFamilies #-}
module Foo where
data family Foo a
data instance Foo Int
= A | B
deriving (Enum)
```
GHC gives 5 error messages, all to line 8 (the deriving clause), in terms of some internal representations of variables and types. I think that an error message should not be of this kind even if the code really contains an error. But here I even do not understand why the code should not be valid. In the case of deriving Eq, Ord, Bounded or Show for the same Foo Int, everything works fine; and also, old good instance declaration instead of deriving gives a normally working code. (Analogous errors are produced when deriving Ix.)
Here is the output of GHCi -v in the case of the above module (GHC gives a similar one):
```
Prelude> :l Foo
*** Chasing dependencies:
Chasing modules from:
Stable obj: []
Stable BCO: []
unload: retaining objs []
unload: retaining bcos []
Ready for upsweep []
Upsweep completely successful.
*** Deleting temp files:
Deleting:
*** Chasing dependencies:
Chasing modules from: *Foo.hs
Stable obj: []
Stable BCO: []
unload: retaining objs []
unload: retaining bcos []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = Mon Aug 2 14:30:44 UTC 2010
ms_mod = main:Foo,
ms_imps = []
ms_srcimps = []
}]
compile: input file Foo.hs
*** Checking old interface for main:Foo:
[1 of 1] Compiling Foo ( Foo.hs, interpreted )
*** Parser:
*** Renamer/typechecker:
Foo.hs:8:12:
Couldn't match expected type `Foo Int'
against inferred type `Foo.R:FooInt'
NB: `Foo' is a type function
In the expression: Foo.$tag2con_R:FooInt ((+) (GHC.Types.I# a#) 1)
In the expression:
if (==) Foo.$maxtag_R:FooInt (GHC.Types.I# a#) then
error
"succ{R:FooInt}: tried to take `succ' of last tag in enumeration"
else
Foo.$tag2con_R:FooInt ((+) (GHC.Types.I# a#) 1)
In a case alternative:
a#
-> if (==) Foo.$maxtag_R:FooInt (GHC.Types.I# a#) then
error
"succ{R:FooInt}: tried to take `succ' of last tag in enumeration"
else
Foo.$tag2con_R:FooInt ((+) (GHC.Types.I# a#) 1)
Foo.hs:8:12:
Couldn't match expected type `Foo Int'
against inferred type `Foo.R:FooInt'
NB: `Foo' is a type function
In the expression: Foo.$tag2con_R:FooInt ((+) (GHC.Types.I# a#) -1)
In the expression:
if (==) 0 (GHC.Types.I# a#) then
error
"pred{R:FooInt}: tried to take `pred' of first tag in enumeration"
else
Foo.$tag2con_R:FooInt ((+) (GHC.Types.I# a#) -1)
In a case alternative:
a#
-> if (==) 0 (GHC.Types.I# a#) then
error
"pred{R:FooInt}: tried to take `pred' of first tag in enumeration"
else
Foo.$tag2con_R:FooInt ((+) (GHC.Types.I# a#) -1)
Foo.hs:8:12:
Couldn't match expected type `Foo Int'
against inferred type `Foo.R:FooInt'
NB: `Foo' is a type function
In the expression: Foo.$tag2con_R:FooInt a
In the expression:
if (&&) ((>=) a 0) ((<=) a Foo.$maxtag_R:FooInt) then
Foo.$tag2con_R:FooInt a
else
error
((++)
"toEnum{R:FooInt}: tag ("
(showsPrec
0
a
((++)
") is outside of enumeration's range (0,"
(showsPrec 0 Foo.$maxtag_R:FooInt ")"))))
In the definition of `toEnum':
toEnum a = if (&&) ((>=) a 0) ((<=) a Foo.$maxtag_R:FooInt) then
Foo.$tag2con_R:FooInt a
else
error
((++)
"toEnum{R:FooInt}: tag ("
(showsPrec
0
a
((++)
") is outside of enumeration's range (0,"
(showsPrec 0 Foo.$maxtag_R:FooInt ")"))))
Foo.hs:8:12:
Couldn't match expected type `Foo Int'
against inferred type `Foo.R:FooInt'
NB: `Foo' is a type function
In the first argument of `map', namely `Foo.$tag2con_R:FooInt'
In the expression:
map
Foo.$tag2con_R:FooInt
(enumFromTo (GHC.Types.I# a#) Foo.$maxtag_R:FooInt)
In a case alternative:
a#
-> map
Foo.$tag2con_R:FooInt
(enumFromTo (GHC.Types.I# a#) Foo.$maxtag_R:FooInt)
Foo.hs:8:12:
Couldn't match expected type `Foo Int'
against inferred type `Foo.R:FooInt'
NB: `Foo' is a type function
In the first argument of `map', namely `Foo.$tag2con_R:FooInt'
In the expression:
map
Foo.$tag2con_R:FooInt
(enumFromThenTo
(GHC.Types.I# a#)
(GHC.Types.I# b#)
(if (>) (GHC.Types.I# a#) (GHC.Types.I# b#) then
0
else
Foo.$maxtag_R:FooInt))
In a case alternative:
b#
-> map
Foo.$tag2con_R:FooInt
(enumFromThenTo
(GHC.Types.I# a#)
(GHC.Types.I# b#)
(if (>) (GHC.Types.I# a#) (GHC.Types.I# b#) then
0
else
Foo.$maxtag_R:FooInt))
*** Deleting temp files:
Deleting:
Upsweep partially successful.
*** Deleting temp files:
Deleting:
Failed, modules loaded: none.
```
Making deriving stand-alone does not help (the error messages would be more or less similar). It seems that the automatically derived code for methods is buggy and does not type-check.
Using GADTs also does not help, but the feedback is different. In the case of GADTs, (stand-alone) deriving does not work for other type classes either. For example, if the module is
```
{-# LANGUAGE GADTs, StandaloneDeriving, FlexibleInstances #-}
module Foo where
data Foo a where
A :: Foo Int
B :: Foo Int
deriving instance (Eq (Foo Int))
```
then GHCi says the following:
```
Foo.hs:1:0:
GADT pattern match in non-rigid context for `A'
Probable solution: add a type signature for `Foo.$con2tag_Foo'
In the pattern: A
In the definition of `Foo.$con2tag_Foo': Foo.$con2tag_Foo A = 0#
```
Note the location of the error according to the message!
Anyway, after deleting the stand-alone deriving, GHCi is satisfied. By the way, :i A then gives:
```
data Foo a where
A :: (a ~ Int) => Foo Int
...
```
However, :t A gives:
```
A :: Foo Int
```
So, is the type system of GHC ambiguous? Why are the types given by :i and :t different?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.3 |
| 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":"deriving Enum fails for data instances","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":["GADTs","deriving,","families,","instance","type"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following sample module does not compile:\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule Foo where\r\n\r\ndata family Foo a\r\n\r\ndata instance Foo Int\r\n = A | B\r\n deriving (Enum)\r\n}}}\r\n\r\nGHC gives 5 error messages, all to line 8 (the deriving clause), in terms of some internal representations of variables and types. I think that an error message should not be of this kind even if the code really contains an error. But here I even do not understand why the code should not be valid. In the case of deriving Eq, Ord, Bounded or Show for the same Foo Int, everything works fine; and also, old good instance declaration instead of deriving gives a normally working code. (Analogous errors are produced when deriving Ix.)\r\n\r\nHere is the output of GHCi -v in the case of the above module (GHC gives a similar one):\r\n\r\n{{{\r\nPrelude> :l Foo\r\n*** Chasing dependencies:\r\nChasing modules from:\r\nStable obj: []\r\nStable BCO: []\r\nunload: retaining objs []\r\nunload: retaining bcos []\r\nReady for upsweep []\r\nUpsweep completely successful.\r\n*** Deleting temp files:\r\nDeleting:\r\n*** Chasing dependencies:\r\nChasing modules from: *Foo.hs\r\nStable obj: []\r\nStable BCO: []\r\nunload: retaining objs []\r\nunload: retaining bcos []\r\nReady for upsweep\r\n [NONREC\r\n ModSummary {\r\n ms_hs_date = Mon Aug 2 14:30:44 UTC 2010\r\n ms_mod = main:Foo,\r\n ms_imps = []\r\n ms_srcimps = []\r\n }]\r\ncompile: input file Foo.hs\r\n*** Checking old interface for main:Foo:\r\n[1 of 1] Compiling Foo ( Foo.hs, interpreted )\r\n*** Parser:\r\n*** Renamer/typechecker:\r\n\r\nFoo.hs:8:12:\r\n Couldn't match expected type `Foo Int'\r\n against inferred type `Foo.R:FooInt'\r\n NB: `Foo' is a type function\r\n In the expression: Foo.$tag2con_R:FooInt ((+) (GHC.Types.I# a#) 1)\r\n In the expression:\r\n if (==) Foo.$maxtag_R:FooInt (GHC.Types.I# a#) then\r\n error\r\n \"succ{R:FooInt}: tried to take `succ' of last tag in enumeration\"\r\n else\r\n Foo.$tag2con_R:FooInt ((+) (GHC.Types.I# a#) 1)\r\n In a case alternative:\r\n a#\r\n -> if (==) Foo.$maxtag_R:FooInt (GHC.Types.I# a#) then\r\n error\r\n \"succ{R:FooInt}: tried to take `succ' of last tag in enumeration\"\r\n else\r\n Foo.$tag2con_R:FooInt ((+) (GHC.Types.I# a#) 1)\r\n\r\nFoo.hs:8:12:\r\n Couldn't match expected type `Foo Int'\r\n against inferred type `Foo.R:FooInt'\r\n NB: `Foo' is a type function\r\n In the expression: Foo.$tag2con_R:FooInt ((+) (GHC.Types.I# a#) -1)\r\n In the expression:\r\n if (==) 0 (GHC.Types.I# a#) then\r\n error\r\n \"pred{R:FooInt}: tried to take `pred' of first tag in enumeration\"\r\n else\r\n Foo.$tag2con_R:FooInt ((+) (GHC.Types.I# a#) -1)\r\n In a case alternative:\r\n a#\r\n -> if (==) 0 (GHC.Types.I# a#) then\r\n error\r\n \"pred{R:FooInt}: tried to take `pred' of first tag in enumeration\"\r\n else\r\n Foo.$tag2con_R:FooInt ((+) (GHC.Types.I# a#) -1)\r\n\r\nFoo.hs:8:12:\r\n Couldn't match expected type `Foo Int'\r\n against inferred type `Foo.R:FooInt'\r\n NB: `Foo' is a type function\r\n In the expression: Foo.$tag2con_R:FooInt a\r\n In the expression:\r\n if (&&) ((>=) a 0) ((<=) a Foo.$maxtag_R:FooInt) then\r\n Foo.$tag2con_R:FooInt a\r\n else\r\n error\r\n ((++)\r\n \"toEnum{R:FooInt}: tag (\"\r\n (showsPrec\r\n 0\r\n a\r\n ((++)\r\n \") is outside of enumeration's range (0,\"\r\n (showsPrec 0 Foo.$maxtag_R:FooInt \")\"))))\r\n In the definition of `toEnum':\r\n toEnum a = if (&&) ((>=) a 0) ((<=) a Foo.$maxtag_R:FooInt) then\r\n Foo.$tag2con_R:FooInt a\r\n else\r\n error\r\n ((++)\r\n \"toEnum{R:FooInt}: tag (\"\r\n (showsPrec\r\n 0\r\n a\r\n ((++)\r\n \") is outside of enumeration's range (0,\"\r\n (showsPrec 0 Foo.$maxtag_R:FooInt \")\"))))\r\n\r\nFoo.hs:8:12:\r\n Couldn't match expected type `Foo Int'\r\n against inferred type `Foo.R:FooInt'\r\n NB: `Foo' is a type function\r\n In the first argument of `map', namely `Foo.$tag2con_R:FooInt'\r\n In the expression:\r\n map\r\n Foo.$tag2con_R:FooInt\r\n (enumFromTo (GHC.Types.I# a#) Foo.$maxtag_R:FooInt)\r\n In a case alternative:\r\n a#\r\n -> map\r\n Foo.$tag2con_R:FooInt\r\n (enumFromTo (GHC.Types.I# a#) Foo.$maxtag_R:FooInt)\r\n\r\nFoo.hs:8:12:\r\n Couldn't match expected type `Foo Int'\r\n against inferred type `Foo.R:FooInt'\r\n NB: `Foo' is a type function\r\n In the first argument of `map', namely `Foo.$tag2con_R:FooInt'\r\n In the expression:\r\n map\r\n Foo.$tag2con_R:FooInt\r\n (enumFromThenTo\r\n (GHC.Types.I# a#)\r\n (GHC.Types.I# b#)\r\n (if (>) (GHC.Types.I# a#) (GHC.Types.I# b#) then\r\n 0\r\n else\r\n Foo.$maxtag_R:FooInt))\r\n In a case alternative:\r\n b#\r\n -> map\r\n Foo.$tag2con_R:FooInt\r\n (enumFromThenTo\r\n (GHC.Types.I# a#)\r\n (GHC.Types.I# b#)\r\n (if (>) (GHC.Types.I# a#) (GHC.Types.I# b#) then\r\n 0\r\n else\r\n Foo.$maxtag_R:FooInt))\r\n*** Deleting temp files:\r\nDeleting:\r\nUpsweep partially successful.\r\n*** Deleting temp files:\r\nDeleting:\r\nFailed, modules loaded: none.\r\n}}}\r\n\r\nMaking deriving stand-alone does not help (the error messages would be more or less similar). It seems that the automatically derived code for methods is buggy and does not type-check.\r\n\r\nUsing GADTs also does not help, but the feedback is different. In the case of GADTs, (stand-alone) deriving does not work for other type classes either. For example, if the module is \r\n\r\n{{{\r\n{-# LANGUAGE GADTs, StandaloneDeriving, FlexibleInstances #-}\r\nmodule Foo where\r\n\r\ndata Foo a where\r\n A :: Foo Int\r\n B :: Foo Int\r\n\r\nderiving instance (Eq (Foo Int))\r\n}}}\r\nthen GHCi says the following:\r\n\r\n{{{\r\nFoo.hs:1:0:\r\n GADT pattern match in non-rigid context for `A'\r\n Probable solution: add a type signature for `Foo.$con2tag_Foo'\r\n In the pattern: A\r\n In the definition of `Foo.$con2tag_Foo': Foo.$con2tag_Foo A = 0#\r\n}}}\r\n\r\nNote the location of the error according to the message! \r\nAnyway, after deleting the stand-alone deriving, GHCi is satisfied. By the way, :i A then gives:\r\n\r\n{{{\r\ndata Foo a where\r\n A :: (a ~ Int) => Foo Int\r\n ...\r\n}}}\r\n\r\nHowever, :t A gives:\r\n\r\n{{{\r\nA :: Foo Int\r\n}}}\r\n\r\nSo, is the type system of GHC ambiguous? Why are the types given by :i and :t different?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4272Typechecker loop with type families2019-07-07T18:59:45ZGhost UserTypechecker loop with type familiesThe following code (which I think is ill-typed) causes GHC to hang, both on 6.12.1 and 6.13.20100616:
```
{-# LANGUAGE TypeFamilies, ScopedTypeVariables, FlexibleContexts #-}
module Crash where
class Family f where
terms :: f a -> a
...The following code (which I think is ill-typed) causes GHC to hang, both on 6.12.1 and 6.13.20100616:
```
{-# LANGUAGE TypeFamilies, ScopedTypeVariables, FlexibleContexts #-}
module Crash where
class Family f where
terms :: f a -> a
class Family (TermFamily a) => TermLike a where
type TermFamily a :: * -> *
laws :: forall a b. TermLike a => TermFamily a a -> b
laws t = prune t (terms (undefined :: TermFamily a a))
prune :: TermLike a => TermFamily a a -> TermFamily a a -> b
prune = undefined
```
The compiler still hangs if I remove the typeclass constraints (everything to the left of a =\>, I mean), but everything else seems to be necessary for the compiler to loop. Using -dshow-passes shows that it's the typechecker that loops.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.13 |
| 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":"Typechecker loop with type families","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code (which I think is ill-typed) causes GHC to hang, both on 6.12.1 and 6.13.20100616:\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies, ScopedTypeVariables, FlexibleContexts #-}\r\nmodule Crash where\r\n\r\nclass Family f where\r\n terms :: f a -> a\r\n\r\nclass Family (TermFamily a) => TermLike a where\r\n type TermFamily a :: * -> *\r\n\r\nlaws :: forall a b. TermLike a => TermFamily a a -> b\r\nlaws t = prune t (terms (undefined :: TermFamily a a))\r\n\r\nprune :: TermLike a => TermFamily a a -> TermFamily a a -> b\r\nprune = undefined\r\n}}}\r\n\r\nThe compiler still hangs if I remove the typeclass constraints (everything to the left of a =>, I mean), but everything else seems to be necessary for the compiler to loop. Using -dshow-passes shows that it's the typechecker that loops.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4284Adding parentheses introduces type error2019-07-07T18:59:42ZjpbernardyAdding parentheses introduces type error```
{-# LANGUAGE RankNTypes #-}
module Test where
foo :: () -> forall b. b
foo = undefined
works = id foo
fails = (id) foo
-- works type checks, but fails fails with the following error
-- message:
--
-- Cannot match a monotype wi...```
{-# LANGUAGE RankNTypes #-}
module Test where
foo :: () -> forall b. b
foo = undefined
works = id foo
fails = (id) foo
-- works type checks, but fails fails with the following error
-- message:
--
-- Cannot match a monotype with `() -> forall b. b'
-- Probable cause: `foo' is applied to too few arguments
-- In the first argument of `(id)', namely `foo'
-- In the expression: (id) foo
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nad |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Adding parentheses introduces type error","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":["higher-rank","polymorphism"],"differentials":[],"test_case":"","architecture":"","cc":["nad"],"type":"Bug","description":"{{{\r\n{-# LANGUAGE RankNTypes #-}\r\n\r\nmodule Test where\r\n\r\nfoo :: () -> forall b. b\r\nfoo = undefined\r\n\r\nworks = id foo\r\n\r\nfails = (id) foo\r\n\r\n-- works type checks, but fails fails with the following error\r\n-- message:\r\n--\r\n-- Cannot match a monotype with `() -> forall b. b'\r\n-- Probable cause: `foo' is applied to too few arguments\r\n-- In the first argument of `(id)', namely `foo'\r\n-- In the expression: (id) foo\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4338weird discrepancies between TFs and FDs in GHC72019-07-07T18:59:28Zillissiusweird discrepancies between TFs and FDs in GHC7I'm trying to do some seemingly equivalent code with GHC7 as of 09/19, using !TypeFamilies on the one hand and !FunctionalDependencies on the other, and my experience is that the TFs version results in some really weird-ass error message...I'm trying to do some seemingly equivalent code with GHC7 as of 09/19, using !TypeFamilies on the one hand and !FunctionalDependencies on the other, and my experience is that the TFs version results in some really weird-ass error messages from the compiler -- and a hang in one case -- whereas the FDs version works just fine. I'm not sure about the errors, though they certainly seem bizarre, but I'm pretty sure the compiler hanging is a bug. (And I assume a hang is morally equivalent to a crash, so I'm marking this as such.)
Here's the version with TFs:
```
{-# LANGUAGE MultiParamTypeClasses, TypeFamilies, FlexibleContexts #-}
class (There a ~ b, BackAgain b ~ a) => Foo a b where
type There a
type BackAgain b
there :: a -> b
back :: b -> a
tickle :: b -> b
instance Foo Char Int where
type There Char = Int
type BackAgain Int = Char
there = fromEnum
back = toEnum
tickle = (+1)
test :: (Foo a b) => a -> a
test = back . tickle . there
main :: IO ()
main = print $ test 'F'
```
and the one with FDs:
```
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}
class Bar a b | a -> b, b -> a where
there :: a -> b
back :: b -> a
tickle :: b -> b
instance Bar Char Int where
there = fromEnum
back = toEnum
tickle = (+1)
test :: (Bar a b) => a -> a
test = back . tickle . there
main :: IO ()
main = print $ test 'F'
```
Are these as functionally-equivalent as they seem, or are there some subtle differences I'm missing? (Is it possible there's some kind of configuration problem on my end?)
In any case, the result is that the TFs version gives me different errors depending on which type signatures I supply or omit, whereas the version with FDs compiles and works correctly in all cases.
The TFs version, if I supply both type signatures (as listed):
```
$ ghc Foo.hs
[1 of 1] Compiling Main ( Foo.hs, Foo.o )
Foo.hs:18:15:
Could not deduce (Foo (BackAgain (There a)) (There a))
from the context (Foo a b)
arising from a use of `tickle'
Possible fix:
add (Foo (BackAgain (There a)) (There a)) to the context of
the type signature for `test'
or add an instance declaration for
(Foo (BackAgain (There a)) (There a))
In the first argument of `(.)', namely `tickle'
In the second argument of `(.)', namely `tickle . there'
In the expression: back . tickle . there
Foo.hs:21:16:
Overlapping instances for Foo Char Int
arising from a use of `test'
Matching instances:
instance Foo Char Int -- Defined at Foo.hs:10:10-21
(The choice depends on the instantiation of `'
To pick the first instance above, use -XIncoherentInstances
when compiling the other instance declarations)
In the second argument of `($)', namely `test 'F''
In the expression: print $ test 'F'
In an equation for `main': main = print $ test 'F'
```
If I leave off the type signature for main, but not test:
```
$ ghc Foo.hs
[1 of 1] Compiling Main ( Foo.hs, Foo.o )
Foo.hs:18:15:
Could not deduce (Foo (BackAgain (There a)) (There a))
from the context (Foo a b)
arising from a use of `tickle'
Possible fix:
add (Foo (BackAgain (There a)) (There a)) to the context of
the type signature for `test'
or add an instance declaration for
(Foo (BackAgain (There a)) (There a))
In the first argument of `(.)', namely `tickle'
In the second argument of `(.)', namely `tickle . there'
In the expression: back . tickle . there
```
If I leave off the signature for test, regardless of whether I supply one for main:
```
$ ghc Foo.hs
[1 of 1] Compiling Main ( Foo.hs, Foo.o )
^C
-- a seemingly infinite loop
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.13 |
| 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":"weird discrepancies between TFs and FDs in GHC7","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm trying to do some seemingly equivalent code with GHC7 as of 09/19, using !TypeFamilies on the one hand and !FunctionalDependencies on the other, and my experience is that the TFs version results in some really weird-ass error messages from the compiler -- and a hang in one case -- whereas the FDs version works just fine. I'm not sure about the errors, though they certainly seem bizarre, but I'm pretty sure the compiler hanging is a bug. (And I assume a hang is morally equivalent to a crash, so I'm marking this as such.)\r\n\r\nHere's the version with TFs:\r\n\r\n{{{\r\n{-# LANGUAGE MultiParamTypeClasses, TypeFamilies, FlexibleContexts #-}\r\n\r\nclass (There a ~ b, BackAgain b ~ a) => Foo a b where\r\n type There a\r\n type BackAgain b\r\n there :: a -> b\r\n back :: b -> a\r\n tickle :: b -> b\r\n\r\ninstance Foo Char Int where\r\n type There Char = Int\r\n type BackAgain Int = Char\r\n there = fromEnum\r\n back = toEnum\r\n tickle = (+1)\r\n\r\ntest :: (Foo a b) => a -> a\r\ntest = back . tickle . there\r\n\r\nmain :: IO ()\r\nmain = print $ test 'F'\r\n}}}\r\n\r\n\r\nand the one with FDs:\r\n\r\n{{{\r\n{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}\r\n\r\nclass Bar a b | a -> b, b -> a where\r\n there :: a -> b\r\n back :: b -> a\r\n tickle :: b -> b\r\n\r\ninstance Bar Char Int where\r\n there = fromEnum\r\n back = toEnum\r\n tickle = (+1)\r\n\r\ntest :: (Bar a b) => a -> a\r\ntest = back . tickle . there\r\n\r\nmain :: IO ()\r\nmain = print $ test 'F'\r\n}}}\r\n\r\nAre these as functionally-equivalent as they seem, or are there some subtle differences I'm missing? (Is it possible there's some kind of configuration problem on my end?)\r\n\r\n\r\nIn any case, the result is that the TFs version gives me different errors depending on which type signatures I supply or omit, whereas the version with FDs compiles and works correctly in all cases.\r\n\r\nThe TFs version, if I supply both type signatures (as listed):\r\n\r\n{{{\r\n$ ghc Foo.hs \r\n[1 of 1] Compiling Main ( Foo.hs, Foo.o )\r\n\r\nFoo.hs:18:15:\r\n Could not deduce (Foo (BackAgain (There a)) (There a))\r\n from the context (Foo a b)\r\n arising from a use of `tickle'\r\n Possible fix:\r\n add (Foo (BackAgain (There a)) (There a)) to the context of\r\n the type signature for `test'\r\n or add an instance declaration for\r\n (Foo (BackAgain (There a)) (There a))\r\n In the first argument of `(.)', namely `tickle'\r\n In the second argument of `(.)', namely `tickle . there'\r\n In the expression: back . tickle . there\r\n\r\nFoo.hs:21:16:\r\n Overlapping instances for Foo Char Int\r\n arising from a use of `test'\r\n Matching instances:\r\n instance Foo Char Int -- Defined at Foo.hs:10:10-21\r\n (The choice depends on the instantiation of `'\r\n To pick the first instance above, use -XIncoherentInstances\r\n when compiling the other instance declarations)\r\n In the second argument of `($)', namely `test 'F''\r\n In the expression: print $ test 'F'\r\n In an equation for `main': main = print $ test 'F'\r\n}}}\r\n\r\n\r\nIf I leave off the type signature for main, but not test:\r\n\r\n{{{\r\n$ ghc Foo.hs \r\n[1 of 1] Compiling Main ( Foo.hs, Foo.o )\r\n\r\nFoo.hs:18:15:\r\n Could not deduce (Foo (BackAgain (There a)) (There a))\r\n from the context (Foo a b)\r\n arising from a use of `tickle'\r\n Possible fix:\r\n add (Foo (BackAgain (There a)) (There a)) to the context of\r\n the type signature for `test'\r\n or add an instance declaration for\r\n (Foo (BackAgain (There a)) (There a))\r\n In the first argument of `(.)', namely `tickle'\r\n In the second argument of `(.)', namely `tickle . there'\r\n In the expression: back . tickle . there\r\n}}}\r\n\r\nIf I leave off the signature for test, regardless of whether I supply one for main:\r\n\r\n{{{\r\n$ ghc Foo.hs \r\n[1 of 1] Compiling Main ( Foo.hs, Foo.o )\r\n^C\r\n-- a seemingly infinite loop\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/4347Bug in unification of polymorphic and not-yet-polymorphic type2019-07-07T18:59:24ZdolioBug in unification of polymorphic and not-yet-polymorphic typeThe new type checker in GHC 7 seems to reject some cases of impredicative instantiation that prior versions allowed. I was initially alerted to this by Simon Marlow, who sent a patch for vector-algorithms removing a use of `($)` where it...The new type checker in GHC 7 seems to reject some cases of impredicative instantiation that prior versions allowed. I was initially alerted to this by Simon Marlow, who sent a patch for vector-algorithms removing a use of `($)` where it would have to be instantiated impredicatively.
Initially, I thought this was due to a planned removal of impredicativity, but this cannot be the case, because:
```
const :: a -> (forall b. b) -> a
```
is accepted by the type checker. However, the simple:
```
id :: (forall a. a) -> (forall b. b)
```
is not, giving an error message:
```
Couldn't match type `b' with `forall a. a'
`b' is a rigid type variable bound by
an expression type signature at <interactive>:1:32
In the expression: id :: (forall a. a) -> (forall b. b)
```
This would seem to indicate that the type is being rewritten to:
```
forall b. (forall a. a) -> b
```
and then the `forall a. a` matched with the bare `b`. It is, of course, fine to rewrite the type this way, since the two are isomorphic, but it is unfortunate that it causes the checker to reject what would otherwise be a valid instantiation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.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":"Asymmetry of (impredicative) instantiation/higher rank types","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The new type checker in GHC 7 seems to reject some cases of impredicative instantiation that prior versions allowed. I was initially alerted to this by Simon Marlow, who sent a patch for vector-algorithms removing a use of {{{($)}}} where it would have to be instantiated impredicatively.\r\n\r\nInitially, I thought this was due to a planned removal of impredicativity, but this cannot be the case, because:\r\n\r\n{{{\r\nconst :: a -> (forall b. b) -> a\r\n}}}\r\n\r\nis accepted by the type checker. However, the simple:\r\n\r\n{{{\r\nid :: (forall a. a) -> (forall b. b)\r\n}}}\r\n\r\nis not, giving an error message:\r\n\r\n{{{\r\n Couldn't match type `b' with `forall a. a'\r\n `b' is a rigid type variable bound by\r\n an expression type signature at <interactive>:1:32\r\n In the expression: id :: (forall a. a) -> (forall b. b)\r\n}}}\r\n\r\nThis would seem to indicate that the type is being rewritten to:\r\n\r\n{{{\r\nforall b. (forall a. a) -> b\r\n}}}\r\n\r\nand then the {{{forall a. a}}} matched with the bare {{{b}}}. It is, of course, fine to rewrite the type this way, since the two are isomorphic, but it is unfortunate that it causes the checker to reject what would otherwise be a valid instantiation.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/4355Coud not deduce (Typeable a) from context (Typeable a, …)2019-07-07T18:59:22ZmaltemCoud not deduce (Typeable a) from context (Typeable a, …)Attached is a module containing code from XMonadContrib that does not type-check anymore with ghc 7.0.1 rc1. I tried to strip the code somewhat down; at least it only depends on base and mtl. Here's the (somewhat irritating) error messag...Attached is a module containing code from XMonadContrib that does not type-check anymore with ghc 7.0.1 rc1. I tried to strip the code somewhat down; at least it only depends on base and mtl. Here's the (somewhat irritating) error message:
```
tcBug.hs:50:30:
Could not deduce (Typeable a)
from the context (Typeable a, Show ts, HList ts a, LayoutClass l a)
arising from a use of `fromMessage'
Possible fix:
add (Typeable a) to the context of the instance declaration
In a stmt of a pattern guard for
an equation for `handleMessage':
Just (Toggle t) <- fromMessage m
In an equation for `handleMessage':
handleMessage mt m
| Just (Toggle t) <- fromMessage m,
i@(Just _) <- find (transformers mt) t
= case currLayout mt of {
EL l det
-> do { l' <- fromMaybe l
`fmap`
handleMessage l (SomeMessage ReleaseResources);
.... }
where
cur = (i == currIndex mt) }
| otherwise
= case currLayout mt of {
EL l det
-> fmap (fmap (\ x -> mt {currLayout = EL x det}))
$ handleMessage l m }
In the instance declaration for `LayoutClass (MultiToggle ts l) a'
tcBug.hs:51:25:
Could not deduce (HList ts a)
from the context (Typeable a,
Show ts,
HList ts a,
LayoutClass l a,
Transformer t a)
arising from a use of `find'
Possible fix:
add (HList ts a) to the context of
the data constructor `Toggle'
or the instance declaration
In a stmt of a pattern guard for
an equation for `handleMessage':
i@(Just _) <- find (transformers mt) t
In a stmt of a pattern guard for
an equation for `handleMessage':
Just (Toggle t) <- fromMessage m
In an equation for `handleMessage':
handleMessage mt m
| Just (Toggle t) <- fromMessage m,
i@(Just _) <- find (transformers mt) t
= case currLayout mt of {
EL l det
-> do { l' <- fromMaybe l
`fmap`
handleMessage l (SomeMessage ReleaseResources);
.... }
where
cur = (i == currIndex mt) }
| otherwise
= case currLayout mt of {
EL l det
-> fmap (fmap (\ x -> mt {currLayout = EL x det}))
$ handleMessage l m }
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.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":"Coud not deduce (Typeable a) from context (Typeable a, …)","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Attached is a module containing code from XMonadContrib that does not type-check anymore with ghc 7.0.1 rc1. I tried to strip the code somewhat down; at least it only depends on base and mtl. Here's the (somewhat irritating) error message:\r\n\r\n{{{\r\ntcBug.hs:50:30:\r\n Could not deduce (Typeable a)\r\n from the context (Typeable a, Show ts, HList ts a, LayoutClass l a)\r\n arising from a use of `fromMessage'\r\n Possible fix:\r\n add (Typeable a) to the context of the instance declaration\r\n In a stmt of a pattern guard for\r\n an equation for `handleMessage':\r\n Just (Toggle t) <- fromMessage m\r\n In an equation for `handleMessage':\r\n handleMessage mt m\r\n | Just (Toggle t) <- fromMessage m,\r\n i@(Just _) <- find (transformers mt) t\r\n = case currLayout mt of {\r\n EL l det\r\n -> do { l' <- fromMaybe l\r\n `fmap`\r\n handleMessage l (SomeMessage ReleaseResources);\r\n .... }\r\n where\r\n cur = (i == currIndex mt) }\r\n | otherwise\r\n = case currLayout mt of {\r\n EL l det\r\n -> fmap (fmap (\\ x -> mt {currLayout = EL x det}))\r\n $ handleMessage l m }\r\n In the instance declaration for `LayoutClass (MultiToggle ts l) a'\r\n\r\ntcBug.hs:51:25:\r\n Could not deduce (HList ts a)\r\n from the context (Typeable a,\r\n Show ts,\r\n HList ts a,\r\n LayoutClass l a,\r\n Transformer t a)\r\n arising from a use of `find'\r\n Possible fix:\r\n add (HList ts a) to the context of\r\n the data constructor `Toggle'\r\n or the instance declaration\r\n In a stmt of a pattern guard for\r\n an equation for `handleMessage':\r\n i@(Just _) <- find (transformers mt) t\r\n In a stmt of a pattern guard for\r\n an equation for `handleMessage':\r\n Just (Toggle t) <- fromMessage m\r\n In an equation for `handleMessage':\r\n handleMessage mt m\r\n | Just (Toggle t) <- fromMessage m,\r\n i@(Just _) <- find (transformers mt) t\r\n = case currLayout mt of {\r\n EL l det\r\n -> do { l' <- fromMaybe l\r\n `fmap`\r\n handleMessage l (SomeMessage ReleaseResources);\r\n .... }\r\n where\r\n cur = (i == currIndex mt) }\r\n | otherwise\r\n = case currLayout mt of {\r\n EL l det\r\n -> fmap (fmap (\\ x -> mt {currLayout = EL x det}))\r\n $ handleMessage l m }\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.0.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/4356type instance doesn't work when the type is (->)2019-07-07T18:59:22ZSjoerd Visschertype instance doesn't work when the type is (->)This doesn't work in 7.0.0.20100924.
It works fine in 6.12.3.
```
{-# LANGUAGE TypeFamilies #-}
type family T t :: * -> * -> *
type instance T Bool = (->)
f :: T Bool Bool Bool
f = not
```
This is the error:
```
Couldn't match typ...This doesn't work in 7.0.0.20100924.
It works fine in 6.12.3.
```
{-# LANGUAGE TypeFamilies #-}
type family T t :: * -> * -> *
type instance T Bool = (->)
f :: T Bool Bool Bool
f = not
```
This is the error:
```
Couldn't match type `T Bool' with `(->)'
Expected type: T Bool Bool Bool
Actual type: Bool -> Bool
In the expression: not
In an equation for `f': f = not
```7.0.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/4358infinite loop on unification with a type family context2019-07-07T18:59:21Zpatrick_premontinfinite loop on unification with a type family contextThe following throws ghc (and ghci) in a loop (ghc-7.0.0.20100925 for i386-unknown-mingw32)
and it eventually aborts with "ghc.exe: out of memory".
```
> {-# LANGUAGE TypeFamilies, Rank2Types, FlexibleContexts #-}
> type family T a
> ...The following throws ghc (and ghci) in a loop (ghc-7.0.0.20100925 for i386-unknown-mingw32)
and it eventually aborts with "ghc.exe: out of memory".
```
> {-# LANGUAGE TypeFamilies, Rank2Types, FlexibleContexts #-}
> type family T a
> t2 :: forall a. ((T a ~ a) => a) -> a
> t2 = t
> t :: forall a. ((T a ~ a) => a) -> a
> t = undefined
```
Using ghc 6.12.1 we do not get a loop, but a puzzling error:
typeBug.lhs:9:7:
Couldn't match expected type `(T a ~ a) => a'
against inferred type `(T a \~ a) =\> a'
Expected type: (T a \~ a) =\> a
Inferred type: (T a \~ a) =\> a
In the expression: t
> In the definition of \`t2': t2 = t
I presume that the non-injectivity of type family T triggers the problem however
the following produces no errors in either version of the compiler.
```
> ok2 :: forall a. T a -> a
> ok2 = ok
> ok :: forall a. T a -> a
> ok = undefined
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.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":"infinite loop on unification with a type family context","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":["context","family","infinite","loop","type"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following throws ghc (and ghci) in a loop (ghc-7.0.0.20100925 for i386-unknown-mingw32)\r\nand it eventually aborts with \"ghc.exe: out of memory\".\r\n\r\n{{{\r\n\r\n> {-# LANGUAGE TypeFamilies, Rank2Types, FlexibleContexts #-}\r\n\r\n> type family T a\r\n\r\n> t2 :: forall a. ((T a ~ a) => a) -> a\r\n> t2 = t\r\n \r\n> t :: forall a. ((T a ~ a) => a) -> a\r\n> t = undefined\r\n\r\n}}}\r\n\r\nUsing ghc 6.12.1 we do not get a loop, but a puzzling error:\r\n\r\ntypeBug.lhs:9:7:\r\n Couldn't match expected type `(T a ~ a) => a'\r\n against inferred type `(T a ~ a) => a'\r\n Expected type: (T a ~ a) => a\r\n Inferred type: (T a ~ a) => a\r\n In the expression: t\r\n In the definition of `t2': t2 = t\r\n\r\nI presume that the non-injectivity of type family T triggers the problem however\r\nthe following produces no errors in either version of the compiler.\r\n\r\n{{{\r\n\r\n> ok2 :: forall a. T a -> a\r\n> ok2 = ok\r\n \r\n> ok :: forall a. T a -> a\r\n> ok = undefined\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4361Typechecker regression2019-07-07T18:59:21ZIan Lynagh <igloo@earth.li>Typechecker regressionHere's the essence of the regression DoCon showed up, reported here:
http://www.haskell.org/pipermail/glasgow-haskell-bugs/2010-September/025511.html
```
{-# LANGUAGE FlexibleContexts #-}
module Pol3_ (moduloBasisx) where
class Commut...Here's the essence of the regression DoCon showed up, reported here:
http://www.haskell.org/pipermail/glasgow-haskell-bugs/2010-September/025511.html
```
{-# LANGUAGE FlexibleContexts #-}
module Pol3_ (moduloBasisx) where
class CommutativeRing a
class CommutativeRing a => LinSolvRing a
class LinSolvRing a => EuclideanRing a
instance EuclideanRing a => LinSolvRing (Pol a)
instance CommutativeRing a => CommutativeRing (Pol a)
data Pol a = MkPol
upLinSolvRing :: LinSolvRing a => a -> ()
upLinSolvRing = undefined
moduloBasisx :: (LinSolvRing (Pol a), CommutativeRing a) => Pol a -> ()
moduloBasisx p = let x = upLinSolvRing p
in ()
```
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.2
$ ghc --make Pol3_
[1 of 1] Compiling Pol3_ ( Pol3_.hs, Pol3_.o )
$
```
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.0.20100924
$ ghc --make Pol3_
[1 of 1] Compiling Pol3_ ( Pol3_.hs, Pol3_.o )
Pol3_.hs:19:26:
Could not deduce (EuclideanRing a)
from the context (LinSolvRing (Pol a), CommutativeRing a)
arising from a use of `upLinSolvRing'
Possible fix:
add (EuclideanRing a) to the context of
the type signature for `moduloBasisx'
In the expression: upLinSolvRing p
In an equation for `x': x = upLinSolvRing p
In the expression: let x = upLinSolvRing p in ()
$
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Typechecker regression","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.0.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here's the essence of the regression DoCon showed up, reported here:\r\nhttp://www.haskell.org/pipermail/glasgow-haskell-bugs/2010-September/025511.html\r\n\r\n{{{\r\n{-# LANGUAGE FlexibleContexts #-}\r\n\r\nmodule Pol3_ (moduloBasisx) where\r\n\r\nclass CommutativeRing a\r\nclass CommutativeRing a => LinSolvRing a\r\nclass LinSolvRing a => EuclideanRing a\r\n\r\ninstance EuclideanRing a => LinSolvRing (Pol a)\r\ninstance CommutativeRing a => CommutativeRing (Pol a)\r\n\r\ndata Pol a = MkPol\r\n\r\nupLinSolvRing :: LinSolvRing a => a -> ()\r\nupLinSolvRing = undefined\r\n\r\nmoduloBasisx :: (LinSolvRing (Pol a), CommutativeRing a) => Pol a -> ()\r\nmoduloBasisx p = let x = upLinSolvRing p\r\n in ()\r\n}}}\r\n\r\n{{{\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.12.2\r\n$ ghc --make Pol3_\r\n[1 of 1] Compiling Pol3_ ( Pol3_.hs, Pol3_.o )\r\n$\r\n}}}\r\n\r\n{{{\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 7.0.0.20100924\r\n$ ghc --make Pol3_\r\n[1 of 1] Compiling Pol3_ ( Pol3_.hs, Pol3_.o )\r\n\r\nPol3_.hs:19:26:\r\n Could not deduce (EuclideanRing a)\r\n from the context (LinSolvRing (Pol a), CommutativeRing a)\r\n arising from a use of `upLinSolvRing'\r\n Possible fix:\r\n add (EuclideanRing a) to the context of\r\n the type signature for `moduloBasisx'\r\n In the expression: upLinSolvRing p\r\n In an equation for `x': x = upLinSolvRing p\r\n In the expression: let x = upLinSolvRing p in ()\r\n$\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.0.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/4364Template Haskell: Cycle in type synonym declarations2019-07-07T18:59:20ZIan Lynagh <igloo@earth.li>Template Haskell: Cycle in type synonym declarations`type-level-numbers-0.1` doesn't build with 7.0.1 RC 1. Here's the essence:
```
{-# LANGUAGE TemplateHaskell #-}
module Q where
data Z
type N0 = $( [t| Z |] )
type N1 = $( [t| Z |] )
```
```
$ ghc --make m.hs
[1 of 1] Compiling Q ...`type-level-numbers-0.1` doesn't build with 7.0.1 RC 1. Here's the essence:
```
{-# LANGUAGE TemplateHaskell #-}
module Q where
data Z
type N0 = $( [t| Z |] )
type N1 = $( [t| Z |] )
```
```
$ ghc --make m.hs
[1 of 1] Compiling Q ( m.hs, m.o )
m.hs:7:1:
Cycle in type synonym declarations:
m.hs:7:1-23: type N0 = $([t| Z |])
m.hs:8:1-23: type N1 = $([t| Z |])
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell: Cycle in type synonym declarations","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.0.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`type-level-numbers-0.1` doesn't build with 7.0.1 RC 1. Here's the essence:\r\n\r\n{{{\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule Q where\r\n\r\ndata Z\r\n\r\ntype N0 = $( [t| Z |] )\r\ntype N1 = $( [t| Z |] )\r\n}}}\r\n\r\n{{{\r\n$ ghc --make m.hs\r\n[1 of 1] Compiling Q ( m.hs, m.o )\r\n\r\nm.hs:7:1:\r\n Cycle in type synonym declarations:\r\n m.hs:7:1-23: type N0 = $([t| Z |])\r\n m.hs:8:1-23: type N1 = $([t| Z |])\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/4385Type-level natural numbers2019-07-07T18:59:14ZIavor S. DiatchkiType-level natural numbersNatural numbers at the type-level have many uses, especially in contexts where programmers need to manipulate data with statically known sizes. A simple form of this feature has been present in many programming languages for a long time ...Natural numbers at the type-level have many uses, especially in contexts where programmers need to manipulate data with statically known sizes. A simple form of this feature has been present in many programming languages for a long time (e.g., sub-range types in Pascal, array type in C, etc.). The feature is particularly useful when combined with polymorphism as illustrated by more recent programming languages (e.g., Cyclone, BlueSpec, Cryptol, Habit).
Existing features of Haskell's type system---such as polymorphism, kinds, and qualified types---make it particularly suitable for adding support for type level naturals in a natural way!
Indeed, there are quite a few Haskell libraries available on Hackage that implement support for type-level numbers in various forms. These libraries are being used by other packages and projects (e.g., the Kansas Lava project, and the type-safe bindings to the LLVM library).
Supporting natural number types directly in the compiler would help these projects, and others, by improving on the existing libraries in the following ways:
- a standard implementation,
- a better notation,
- better error messages,
- a more efficient implementation,
- more complete support for numeric operations.
I have started on an implementation of this feature, and my GHC branch is available in a darcs repository at the following URL:
```
http://code.galois.com/darcs/ghc-type-naturals/
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | |
| 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":"Type-level natural numbers","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"diatchki"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Natural numbers at the type-level have many uses, especially in contexts where programmers need to manipulate data with statically known sizes. A simple form of this feature has been present in many programming languages for a long time (e.g., sub-range types in Pascal, array type in C, etc.). The feature is particularly useful when combined with polymorphism as illustrated by more recent programming languages (e.g., Cyclone, BlueSpec, Cryptol, Habit).\r\n\r\nExisting features of Haskell's type system---such as polymorphism, kinds, and qualified types---make it particularly suitable for adding support for type level naturals in a natural way!\r\n\r\nIndeed, there are quite a few Haskell libraries available on Hackage that implement support for type-level numbers in various forms. These libraries are being used by other packages and projects (e.g., the Kansas Lava project, and the type-safe bindings to the LLVM library).\r\n\r\nSupporting natural number types directly in the compiler would help these projects, and others, by improving on the existing libraries in the following ways:\r\n * a standard implementation,\r\n * a better notation,\r\n * better error messages,\r\n * a more efficient implementation,\r\n * more complete support for numeric operations.\r\n\r\nI have started on an implementation of this feature, and my GHC branch is available in a darcs repository at the following URL:\r\n{{{\r\nhttp://code.galois.com/darcs/ghc-type-naturals/\r\n}}}\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Iavor S. DiatchkiIavor S. Diatchkihttps://gitlab.haskell.org/ghc/ghc/-/issues/4392tcrun020 failure2019-07-07T18:59:13ZSimon Marlowtcrun020 failure```
tcrun020 is currently failing all ways:
=====> tcrun020(normal) 1947 of 2622 [0, 12, 0]
cd ./typecheck/should_run && '/64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown-linux/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lin...```
tcrun020 is currently failing all ways:
=====> tcrun020(normal) 1947 of 2622 [0, 12, 0]
cd ./typecheck/should_run && '/64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown-linux/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -o tcrun020 tcrun020.hs >tcrun020.comp.stderr 2>&1
Compile failed (status 256) errors were:
[1 of 1] Compiling Main ( tcrun020.hs, tcrun020.o )
tcrun020.hs:15:21:
Illegal instance declaration for `C1 m Bool'
(All instance types must be of the form (T a1 ... an)
where a1 ... an are type *variables*,
and each type variable appears at most once in the instance head.
Use -XFlexibleInstances if you want to disable this.)
In the instance declaration for `C1 m Bool'
*** unexpected failure for tcrun020(normal)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"tcrun020 failure","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\ntcrun020 is currently failing all ways:\r\n\r\n=====> tcrun020(normal) 1947 of 2622 [0, 12, 0]\r\ncd ./typecheck/should_run && '/64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown-linux/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -o tcrun020 tcrun020.hs >tcrun020.comp.stderr 2>&1\r\nCompile failed (status 256) errors were:\r\n[1 of 1] Compiling Main ( tcrun020.hs, tcrun020.o )\r\n\r\ntcrun020.hs:15:21:\r\n Illegal instance declaration for `C1 m Bool'\r\n (All instance types must be of the form (T a1 ... an)\r\n where a1 ... an are type *variables*,\r\n and each type variable appears at most once in the instance head.\r\n Use -XFlexibleInstances if you want to disable this.)\r\n In the instance declaration for `C1 m Bool'\r\n\r\n*** unexpected failure for tcrun020(normal)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4394IPRun failure2021-11-02T09:27:32ZSimon MarlowIPRun failuretypecheck/should_run/IPRun is currently failing all ways:
```
=====> IPRun(normal) 1973 of 2622 [0, 24, 0]
cd ./typecheck/should_run && '/64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown-linux/inplace/bin/ghc-stage2' -fforce-re...typecheck/should_run/IPRun is currently failing all ways:
```
=====> IPRun(normal) 1973 of 2622 [0, 24, 0]
cd ./typecheck/should_run && '/64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown-linux/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -o IPRun IPRun.hs >IPRun.comp.stderr 2>&1
Compile failed (status 256) errors were:
[1 of 1] Compiling Main ( IPRun.hs, IPRun.o )
IPRun.hs:13:18:
Ambiguous type variable `a' in the constraint:
(Num a) arising from the literal `5'
Probable fix: add a type signature that fixes these type variable(s)
In the expression: 5
In the expression: let ?x = 5 in \ () -> ?x
In an equation for `f2': f2 () = let ?x = 5 in \ () -> ?x
IPRun.hs:24:13:
Ambiguous type variable `a1' in the constraint:
(Show a1) arising from a use of `print'
Probable fix: add a type signature that fixes these type variable(s)
In a stmt of a 'do' expression: print (f2 () ())
In the expression:
do { print (f0 ());
print (f1 ());
print (f2 () ());
print (f3 ()) }
In the expression:
let ?x = 0
in
do { print (f0 ());
print (f1 ());
print (f2 () ());
.... }
*** unexpected failure for IPRun(normal)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"IPRun failure","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"typecheck/should_run/IPRun is currently failing all ways:\r\n\r\n{{{\r\n=====> IPRun(normal) 1973 of 2622 [0, 24, 0]\r\ncd ./typecheck/should_run && '/64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown-linux/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -o IPRun IPRun.hs >IPRun.comp.stderr 2>&1\r\nCompile failed (status 256) errors were:\r\n[1 of 1] Compiling Main ( IPRun.hs, IPRun.o )\r\n\r\nIPRun.hs:13:18:\r\n Ambiguous type variable `a' in the constraint:\r\n (Num a) arising from the literal `5'\r\n Probable fix: add a type signature that fixes these type variable(s)\r\n In the expression: 5\r\n In the expression: let ?x = 5 in \\ () -> ?x\r\n In an equation for `f2': f2 () = let ?x = 5 in \\ () -> ?x\r\n\r\nIPRun.hs:24:13:\r\n Ambiguous type variable `a1' in the constraint:\r\n (Show a1) arising from a use of `print'\r\n Probable fix: add a type signature that fixes these type variable(s)\r\n In a stmt of a 'do' expression: print (f2 () ())\r\n In the expression:\r\n do { print (f0 ());\r\n print (f1 ());\r\n print (f2 () ());\r\n print (f3 ()) }\r\n In the expression:\r\n let ?x = 0\r\n in\r\n do { print (f0 ());\r\n print (f1 ());\r\n print (f2 () ());\r\n .... }\r\n\r\n*** unexpected failure for IPRun(normal)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4395T1735(ghci) failing with core-lint error2019-07-07T18:59:12ZSimon MarlowT1735(ghci) failing with core-lint errorexcerpt from the error message:
```
GHCi, version 7.1.20101013: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ....excerpt from the error message:
```
GHCi, version 7.1.20101013: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
[1 of 6] Compiling T1735_Help.Context ( T1735_Help/Context.hs, interpreted )
[2 of 6] Compiling T1735_Help.State ( T1735_Help/State.hs, interpreted )
[3 of 6] Compiling T1735_Help.Basics ( T1735_Help/Basics.hs, interpreted )
[4 of 6] Compiling T1735_Help.Instances ( T1735_Help/Instances.hs, interpreted )
[5 of 6] Compiling T1735_Help.Xml ( T1735_Help/Xml.hs, interpreted )
*** Core Lint errors : in result of Tidy Core ***
{-# LINE 122 "T1735_Help/Xml.hs #-}:
[RHS of T1735_Help.Xml.typeNotValue :: forall a_a1NJ.
T1735_Help.Xml.Xml a_a1NJ =>
a_a1NJ -> a_a1NJ]
Demand type has 2 arguments, rhs has 1 arguments, T1735_Help.Xml.typeNotValue
Binder's strictness signature: DmdType TTb
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"T1735(ghci) failing with core-lint error","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"excerpt from the error message:\r\n\r\n{{{\r\nGHCi, version 7.1.20101013: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\n[1 of 6] Compiling T1735_Help.Context ( T1735_Help/Context.hs, interpreted )\r\n[2 of 6] Compiling T1735_Help.State ( T1735_Help/State.hs, interpreted )\r\n[3 of 6] Compiling T1735_Help.Basics ( T1735_Help/Basics.hs, interpreted )\r\n[4 of 6] Compiling T1735_Help.Instances ( T1735_Help/Instances.hs, interpreted )\r\n[5 of 6] Compiling T1735_Help.Xml ( T1735_Help/Xml.hs, interpreted )\r\n*** Core Lint errors : in result of Tidy Core ***\r\n{-# LINE 122 \"T1735_Help/Xml.hs #-}:\r\n [RHS of T1735_Help.Xml.typeNotValue :: forall a_a1NJ.\r\n T1735_Help.Xml.Xml a_a1NJ =>\r\n a_a1NJ -> a_a1NJ]\r\n Demand type has 2 arguments, rhs has 1 arguments, T1735_Help.Xml.typeNotValue\r\n Binder's strictness signature: DmdType TTb\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.0.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/4396tc003(hpc) failing with link error2019-07-07T18:59:12ZSimon Marlowtc003(hpc) failing with link error```
=====> tc003(hpc) 1980 of 2622 [0, 37, 0]
cd ./typecheck/should_compile && '/64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown-linux/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-pac...```
=====> tc003(hpc) 1980 of 2622 [0, 37, 0]
cd ./typecheck/should_compile && '/64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown-linux/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -c tc003.hs -O -fhpc -fno-warn-incomplete-patterns >tc003.comp.stderr 2>&1
Compile failed (status 256) errors were:
/tmp/ghc14267_0/ghc14267_0.s: Assembler messages:
/tmp/ghc14267_0/ghc14267_0.s:173:0:
Error: symbol `ShouldSucceed_e_closure' is already defined
/tmp/ghc14267_0/ghc14267_0.s:196:0:
Error: symbol `ShouldSucceed_e_info' is already defined
/tmp/ghc14267_0/ghc14267_0.s:237:0:
Error: symbol `ShouldSucceed_d_closure' is already defined
/tmp/ghc14267_0/ghc14267_0.s:260:0:
Error: symbol `ShouldSucceed_d_info' is already defined
*** unexpected failure for tc003(hpc)
```
Apparently the simplifier is generating multiple bindings for `d` and `e`. (Core Lint ought to check for this too).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"tc003(hpc) failing with link error","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n=====> tc003(hpc) 1980 of 2622 [0, 37, 0]\r\ncd ./typecheck/should_compile && '/64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown-linux/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -c tc003.hs -O -fhpc -fno-warn-incomplete-patterns >tc003.comp.stderr 2>&1\r\nCompile failed (status 256) errors were:\r\n/tmp/ghc14267_0/ghc14267_0.s: Assembler messages:\r\n\r\n/tmp/ghc14267_0/ghc14267_0.s:173:0:\r\n Error: symbol `ShouldSucceed_e_closure' is already defined\r\n\r\n/tmp/ghc14267_0/ghc14267_0.s:196:0:\r\n Error: symbol `ShouldSucceed_e_info' is already defined\r\n\r\n/tmp/ghc14267_0/ghc14267_0.s:237:0:\r\n Error: symbol `ShouldSucceed_d_closure' is already defined\r\n\r\n/tmp/ghc14267_0/ghc14267_0.s:260:0:\r\n Error: symbol `ShouldSucceed_d_info' is already defined\r\n\r\n*** unexpected failure for tc003(hpc)\r\n}}}\r\n\r\nApparently the simplifier is generating multiple bindings for `d` and `e`. (Core Lint ought to check for this too).","type_of_failure":"OtherFailure","blocking":[]} -->7.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4404RecordWildCards2019-07-07T18:59:10ZIan Lynagh <igloo@earth.li>RecordWildCardsWith this module:
```
{-# LANGUAGE RecordWildCards #-}
module TT where
data T = T {t1, t2 :: Int}
f :: T -> Int
f d = x
where T {t1 = x, ..} = d
g :: T -> Int
g (T {t1 = x, ..}) = x
```
`f` gives warnings about t2 being unused:...With this module:
```
{-# LANGUAGE RecordWildCards #-}
module TT where
data T = T {t1, t2 :: Int}
f :: T -> Int
f d = x
where T {t1 = x, ..} = d
g :: T -> Int
g (T {t1 = x, ..}) = x
```
`f` gives warnings about t2 being unused:
```
$ ghc -Wall -c n.hs
n.hs:9:11: Warning: Defined but not used: `t2'
```
which is probably not what we want for variables bound by a wildcard. Reported by Serge here:
http://www.haskell.org/pipermail/glasgow-haskell-bugs/2010-October/025858.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.3 |
| 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":"RecordWildCards","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With this module:\r\n{{{\r\n{-# LANGUAGE RecordWildCards #-}\r\n\r\nmodule TT where\r\n\r\ndata T = T {t1, t2 :: Int}\r\n\r\nf :: T -> Int\r\nf d = x\r\n where T {t1 = x, ..} = d\r\n\r\ng :: T -> Int\r\ng (T {t1 = x, ..}) = x\r\n}}}\r\n`f` gives warnings about t2 being unused:\r\n{{{\r\n$ ghc -Wall -c n.hs\r\n\r\nn.hs:9:11: Warning: Defined but not used: `t2'\r\n}}}\r\nwhich is probably not what we want for variables bound by a wildcard. Reported by Serge here:\r\nhttp://www.haskell.org/pipermail/glasgow-haskell-bugs/2010-October/025858.html\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/4418Superclass functional dependencies are ignored during instance selection2019-07-07T18:59:06ZreinerpSuperclass functional dependencies are ignored during instance selectionThe following example compiles with ghc-6.12.3, but not with ghc-7.0.0.20100924:
```
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}
module Ambiguity where
class C1 a b | b -> a
class (C1 a b) => C2 a b where
foo :: b...The following example compiles with ghc-6.12.3, but not with ghc-7.0.0.20100924:
```
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}
module Ambiguity where
class C1 a b | b -> a
class (C1 a b) => C2 a b where
foo :: b -> b
data A = A
data B = B
instance C1 A B
instance C2 A B
-- this is accepted by both 6.12.3 and 7
runFoo :: C2 a b => b -> b
runFoo = foo
-- this is accepted by 6.12.3, but not by 7
runFoo2 :: B -> B
runFoo2 = foo
```
A straightforward fix is to add the `b -> a` fundep to the `C2` class as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.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":"Superclass functional dependencies are ignored during instance selection","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following example compiles with ghc-6.12.3, but not with ghc-7.0.0.20100924:\r\n{{{\r\n{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}\r\n\r\nmodule Ambiguity where\r\n\r\nclass C1 a b | b -> a\r\nclass (C1 a b) => C2 a b where\r\n foo :: b -> b\r\n\r\ndata A = A\r\ndata B = B\r\ninstance C1 A B\r\ninstance C2 A B\r\n\r\n-- this is accepted by both 6.12.3 and 7\r\nrunFoo :: C2 a b => b -> b\r\nrunFoo = foo\r\n\r\n-- this is accepted by 6.12.3, but not by 7\r\nrunFoo2 :: B -> B\r\nrunFoo2 = foo\r\n}}}\r\n\r\nA straightforward fix is to add the {{{b -> a}}} fundep to the {{{C2}}} class as well.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4479Implement TDNR2021-01-08T20:29:07ZgidynImplement TDNRA request to implement [TDNR](https://wiki.haskell.org/TypeDirectedNameResolution).A request to implement [TDNR](https://wiki.haskell.org/TypeDirectedNameResolution).8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4482Allow type variables to be instantiated as a typeclass2019-07-07T18:58:47ZgidynAllow type variables to be instantiated as a typeclassAllow code such as
```
x = [1,True]::[Show]
```
This would eliminate the need for manual wrapper types, which bloat code with type plumbing.
<details><summary>Trac metadata</summary>
| Trac field | Value ...Allow code such as
```
x = [1,True]::[Show]
```
This would eliminate the need for manual wrapper types, which bloat code with type plumbing.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | gideon@accursoft.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Allow type variables to be instantiated as a typeclass","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["gideon@accursoft.com"],"type":"Bug","description":"Allow code such as\r\n{{{\r\nx = [1,True]::[Show]\r\n}}}\r\nThis would eliminate the need for manual wrapper types, which bloat code with type plumbing.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/4492Type families regression2021-01-03T00:19:55Zrl@cse.unsw.edu.auType families regressionHere is a small program:
```
type family F a b
type instance F (Maybe a) b = b -> F a b
class C a where
go :: (forall a. Maybe a -> b -> a) -> a -> F a b
instance C a => C (Maybe a) where
go f a b = go f (f a b)
```
The current h...Here is a small program:
```
type family F a b
type instance F (Maybe a) b = b -> F a b
class C a where
go :: (forall a. Maybe a -> b -> a) -> a -> F a b
instance C a => C (Maybe a) where
go f a b = go f (f a b)
```
The current head complains:
```
Could not deduce (F a b ~ F a b) from the context (C a)
NB: `F' is a type function, and may not be injective
Expected type: b -> F a b
Actual type: F (Maybe a) b
```
1. 12.3 accepts it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.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":"Type families regression","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here is a small program:\r\n\r\n{{{\r\ntype family F a b\r\ntype instance F (Maybe a) b = b -> F a b\r\n\r\nclass C a where\r\n go :: (forall a. Maybe a -> b -> a) -> a -> F a b\r\n\r\ninstance C a => C (Maybe a) where\r\n go f a b = go f (f a b)\r\n}}}\r\n\r\nThe current head complains:\r\n\r\n{{{\r\n Could not deduce (F a b ~ F a b) from the context (C a)\r\n NB: `F' is a type function, and may not be injective\r\n Expected type: b -> F a b\r\n Actual type: F (Maybe a) b\r\n}}}\r\n\r\n6.12.3 accepts it.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4494Another regression with type families2019-07-07T18:58:44Zrl@cse.unsw.edu.auAnother regression with type familiesProgram (compile with !ScopedTypeVariables):
```
type family H s a b
class D (G v) => C v where
type G v
type F v
foo :: v -> H (F v) (G v) v
class D s where
bar :: (forall t. Maybe t -> a) -> s -> H a s r -> r
call :: forall...Program (compile with !ScopedTypeVariables):
```
type family H s a b
class D (G v) => C v where
type G v
type F v
foo :: v -> H (F v) (G v) v
class D s where
bar :: (forall t. Maybe t -> a) -> s -> H a s r -> r
call :: forall v. C v => F v -> v
call x = bar (\_ -> x)
(undefined :: G v)
(foo (undefined :: v))
bar' :: C v => (forall t. Maybe t -> F v) -> G v -> H (F v) (G v) v -> v
bar' = bar
```
The current head (even with today's typechecker patch) complains:
```
Could not deduce (H a (G v) v ~ H (F v) (G v) v)
from the context (C v)
```
But if I change `bar` to `bar'` in the rhs of `foo`, it all works fine. 6.12.3 accepts both programs.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.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":"Another regression with type families","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Program (compile with !ScopedTypeVariables):\r\n\r\n{{{\r\ntype family H s a b\r\n\r\nclass D (G v) => C v where\r\n type G v\r\n type F v\r\n foo :: v -> H (F v) (G v) v\r\n\r\nclass D s where\r\n bar :: (forall t. Maybe t -> a) -> s -> H a s r -> r\r\n\r\ncall :: forall v. C v => F v -> v\r\ncall x = bar (\\_ -> x)\r\n (undefined :: G v)\r\n (foo (undefined :: v))\r\n\r\nbar' :: C v => (forall t. Maybe t -> F v) -> G v -> H (F v) (G v) v -> v\r\nbar' = bar\r\n}}}\r\n\r\nThe current head (even with today's typechecker patch) complains:\r\n\r\n{{{\r\n Could not deduce (H a (G v) v ~ H (F v) (G v) v)\r\n from the context (C v)\r\n}}}\r\n\r\nBut if I change `bar` to `bar'` in the rhs of `foo`, it all works fine. 6.12.3 accepts both programs.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4499"skolem type variable" is bad for usability (and beginners)2019-07-07T18:58:43Zguest"skolem type variable" is bad for usability (and beginners)I believe the new type error message in GHC7 that mentions "skolem" is a hindrance to usability because "skolem" is not a well known term, even in the Haskell community.
I believe using this terminology, even though correct, is going to...I believe the new type error message in GHC7 that mentions "skolem" is a hindrance to usability because "skolem" is not a well known term, even in the Haskell community.
I believe using this terminology, even though correct, is going to confuse people. When I do a google search for:
> haskell skolem type variable
This wiki page does show up:
http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7
Which is great, but after reading it I still don't know \*what\* a skolem type variable is. I now have a trick for working around some instances of the problem created by the changes in the ghc7 type checker, but I'm still none of the wiser as to what is skolem (or why I should care).
I consider this change in error message text to be a regression in the usability of GHC, which in version 6 had the best type error messages of any Haskell compiler. I don't think mentioning skolem is a bad thing (interested parties will learn about skolems), but I think throwing the term around as if the average Haskell programmer already knows what it means is a regression.
Please consider rephrasing this error message.
In the example from the wiki page linked above, what about changing the error message to be similar to this:
```
Foo.hs:7:11:
Couldn't match type `s' with `s1'
because the type variable `s' would escape: `s1'
Hint: `s' is a skolem type variable
The type variable `s' bound by the polymorphic type `forall s. ST s a'
The following variables have types that mention s
fill :: STRef s a -> ST s () (bound at Foo.hs:10:11)
In the first argument of `runST', namely
`(do { r <- newSTRef x; fill r; readSTRef r })'
```
My point is that the new term, skolem, is de-emphasized but still mentioned for the sake of googling and experts.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | dagitj@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"skolem type variable\" is bad for usability (and beginners)","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":["skolem"],"differentials":[],"test_case":"","architecture":"","cc":["dagitj@gmail.com"],"type":"Bug","description":"I believe the new type error message in GHC7 that mentions \"skolem\" is a hindrance to usability because \"skolem\" is not a well known term, even in the Haskell community.\r\n\r\nI believe using this terminology, even though correct, is going to confuse people. When I do a google search for:\r\n haskell skolem type variable\r\n\r\nThis wiki page does show up:\r\nhttp://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7\r\n\r\nWhich is great, but after reading it I still don't know *what* a skolem type variable is. I now have a trick for working around some instances of the problem created by the changes in the ghc7 type checker, but I'm still none of the wiser as to what is skolem (or why I should care).\r\n\r\nI consider this change in error message text to be a regression in the usability of GHC, which in version 6 had the best type error messages of any Haskell compiler. I don't think mentioning skolem is a bad thing (interested parties will learn about skolems), but I think throwing the term around as if the average Haskell programmer already knows what it means is a regression.\r\n\r\nPlease consider rephrasing this error message.\r\n\r\nIn the example from the wiki page linked above, what about changing the error message to be similar to this:\r\n{{{\r\nFoo.hs:7:11:\r\n Couldn't match type `s' with `s1'\r\n because the type variable `s' would escape: `s1'\r\n Hint: `s' is a skolem type variable\r\n The type variable `s' bound by the polymorphic type `forall s. ST s a'\r\n The following variables have types that mention s\r\n fill :: STRef s a -> ST s () (bound at Foo.hs:10:11)\r\n In the first argument of `runST', namely\r\n `(do { r <- newSTRef x; fill r; readSTRef r })'\r\n}}}\r\n\r\nMy point is that the new term, skolem, is de-emphasized but still mentioned for the sake of googling and experts.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4524Template variable unbound in rewrite rule2019-07-07T18:58:34ZguestTemplate variable unbound in rewrite ruleI was trying to compile the latest darcs source (darcs get --lazy http://darcs.net) using ghc7. I had to modify darcs.cabal to add !NoMonoLocalBinds to 3 places (just search for extensions, and add it to the END of the lists).
When I do...I was trying to compile the latest darcs source (darcs get --lazy http://darcs.net) using ghc7. I had to modify darcs.cabal to add !NoMonoLocalBinds to 3 places (just search for extensions, and add it to the END of the lists).
When I do a build I get this:
```
[ 65 of 154] Compiling Darcs.Patch.V1.Commute ( src/Darcs/Patch/V1/Commute.lhs, dist/build/Darcs/Patch/V1/Commute.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.0.1 for i386-unknown-linux):
Template variable unbound in rewrite rule
sg_s2vkQ{tv} [co]
[x{tv a2uFt} [sk], y{tv a2uFu} [sk], sg_s2vkQ{tv} [co],
sc_s2vkR{v} [lid], sc_s2vkS{v} [lid]]
[x{tv X2uJc} [sk], y{tv X2uJe} [sk], sg_s2vkQ{tv} [co],
sc_s2vkR{v} [lid], sc_s2vkS{v} [lid]]
[TYPE y{tv a2uFu} [sk], TYPE y{tv a2uFu} [sk],
TYPE x{tv a2uFt} [sk], TYPE x{tv a2uFt} [sk],
TYPE x{tv a2uFt} [sk], sc_s2vkS{v} [lid], sc_s2vkR{v} [lid],
darcs-2.5:Darcs.Witnesses.Ordered.NilRL{v ruI5} [gid[DataCon]]
@ darcs-2.5:Darcs.Patch.V1.Core.Patch{tc r1EYF}
@ x{tv a2uFt} [sk]
@ x{tv a2uFt} [sk]
@ x{tv a2uFt} [sk]]
[TYPE y{tv a2uFu} [sk], TYPE y{tv a2uFu} [sk],
TYPE x{tv a2uFt} [sk], TYPE x{tv a2uFt} [sk],
TYPE x{tv a2uFt} [sk], wild_s2vhT{v} [lid], sc_s2vke{v} [lid],
darcs-2.5:Darcs.Witnesses.Ordered.NilRL{v ruI5} [gid[DataCon]]
@ darcs-2.5:Darcs.Patch.V1.Core.Patch{tc r1EYF}
@ x{tv a2uFt} [sk]
@ x{tv a2uFt} [sk]
@ x{tv a2uFt} [sk]]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
As an additional data point, this module builds correctly without !NoMonoLocalBinds. The reason I was adding !NoMonoLocalBinds to the .cabal file is because I can't use `#if __GLASGOW_HASKELL >= 700` to conditionally add in this language flag. The reason is because ghc6 will not correctly understand the language flag appearing inside a CPP \#if/\#endif block and I want this code to compile on ghc6 and 7.
Please let me know if I can provide additional information to help reproduce this bug. My email address is dagitj on gmail, also on CC of this ticket.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | dagitj@gmail.com |
| Operating system | Unknown/Multiple |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Template variable unbound in rewrite rule","status":"New","operating_system":"Unknown/Multiple","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":["dagitj@gmail.com"],"type":"Bug","description":"I was trying to compile the latest darcs source (darcs get --lazy http://darcs.net) using ghc7. I had to modify darcs.cabal to add !NoMonoLocalBinds to 3 places (just search for extensions, and add it to the END of the lists).\r\n\r\nWhen I do a build I get this:\r\n{{{\r\n[ 65 of 154] Compiling Darcs.Patch.V1.Commute ( src/Darcs/Patch/V1/Commute.lhs, dist/build/Darcs/Patch/V1/Commute.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.0.1 for i386-unknown-linux):\r\n\tTemplate variable unbound in rewrite rule\r\n sg_s2vkQ{tv} [co]\r\n [x{tv a2uFt} [sk], y{tv a2uFu} [sk], sg_s2vkQ{tv} [co],\r\n sc_s2vkR{v} [lid], sc_s2vkS{v} [lid]]\r\n [x{tv X2uJc} [sk], y{tv X2uJe} [sk], sg_s2vkQ{tv} [co],\r\n sc_s2vkR{v} [lid], sc_s2vkS{v} [lid]]\r\n [TYPE y{tv a2uFu} [sk], TYPE y{tv a2uFu} [sk],\r\n TYPE x{tv a2uFt} [sk], TYPE x{tv a2uFt} [sk],\r\n TYPE x{tv a2uFt} [sk], sc_s2vkS{v} [lid], sc_s2vkR{v} [lid],\r\n darcs-2.5:Darcs.Witnesses.Ordered.NilRL{v ruI5} [gid[DataCon]]\r\n @ darcs-2.5:Darcs.Patch.V1.Core.Patch{tc r1EYF}\r\n @ x{tv a2uFt} [sk]\r\n @ x{tv a2uFt} [sk]\r\n @ x{tv a2uFt} [sk]]\r\n [TYPE y{tv a2uFu} [sk], TYPE y{tv a2uFu} [sk],\r\n TYPE x{tv a2uFt} [sk], TYPE x{tv a2uFt} [sk],\r\n TYPE x{tv a2uFt} [sk], wild_s2vhT{v} [lid], sc_s2vke{v} [lid],\r\n darcs-2.5:Darcs.Witnesses.Ordered.NilRL{v ruI5} [gid[DataCon]]\r\n @ darcs-2.5:Darcs.Patch.V1.Core.Patch{tc r1EYF}\r\n @ x{tv a2uFt} [sk]\r\n @ x{tv a2uFt} [sk]\r\n @ x{tv a2uFt} [sk]]\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nAs an additional data point, this module builds correctly without !NoMonoLocalBinds. The reason I was adding !NoMonoLocalBinds to the .cabal file is because I can't use `#if __GLASGOW_HASKELL >= 700` to conditionally add in this language flag. The reason is because ghc6 will not correctly understand the language flag appearing inside a CPP #if/#endif block and I want this code to compile on ghc6 and 7.\r\n\r\nPlease let me know if I can provide additional information to help reproduce this bug. My email address is dagitj on gmail, also on CC of this ticket.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4525Type synonyms not expanded consistently in errors2019-07-07T18:58:34ZIan Lynagh <igloo@earth.li>Type synonyms not expanded consistently in errorsWith this module:
```
type Foo = Int
x :: Char
x = f
f :: Foo
f = 5
```
GHC says:
```
g.hs:5:5:
Couldn't match expected type `Char' with actual type `Int'
Expected type: Char
Actual type: Foo
In the expression: f
...With this module:
```
type Foo = Int
x :: Char
x = f
f :: Foo
f = 5
```
GHC says:
```
g.hs:5:5:
Couldn't match expected type `Char' with actual type `Int'
Expected type: Char
Actual type: Foo
In the expression: f
In an equation for `x': x = f
```
Note that the first line talks about `Int`, whereas the third line talks about `Foo`. I'd expect both to talk about `Foo`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.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":"Type synonyms not expanded consistently in errors","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With this module:\r\n{{{\r\ntype Foo = Int\r\n\r\nx :: Char\r\nx = f\r\n\r\nf :: Foo\r\nf = 5\r\n}}}\r\nGHC says:\r\n{{{\r\ng.hs:5:5:\r\n Couldn't match expected type `Char' with actual type `Int'\r\n Expected type: Char\r\n Actual type: Foo\r\n In the expression: f\r\n In an equation for `x': x = f\r\n}}}\r\nNote that the first line talks about `Int`, whereas the third line talks about `Foo`. I'd expect both to talk about `Foo`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/4528stand-alone deriving sometimes fails for GADTs2019-07-07T18:58:33Znestrastand-alone deriving sometimes fails for GADTsConsider the following module
```
{-# LANGUAGE GADTs, StandaloneDeriving #-}
module Foo where
data Foo a where
A, B :: Foo Int
deriving instance Enum (Foo a)
```
Loading it into GHCi causes the following message:
```
ghc: panic! (...Consider the following module
```
{-# LANGUAGE GADTs, StandaloneDeriving #-}
module Foo where
data Foo a where
A, B :: Foo Int
deriving instance Enum (Foo a)
```
Loading it into GHCi causes the following message:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.0.1 for x86_64-unknown-linux):
maybe_is_tagToEnum_call.extract_constr_Ids
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
In the case of Bounded instead of Enum in the original code, it does not work either but the error message is more "even-tempered":
```
Foo.hs:7:1:
Couldn't match type `a' with `Int'
`a' is a rigid type variable bound by
the instance declaration at Foo.hs:7:32
In the expression: A
In an equation for `minBound': minBound = A
When typechecking the code for `minBound'
in a standalone derived instance for `Bounded (Foo a)':
To see the code I am typechecking, use -ddump-deriv
In the instance declaration for `Bounded (Foo a)'
Foo.hs:7:1:
Couldn't match type `a' with `Int'
`a' is a rigid type variable bound by
the instance declaration at Foo.hs:7:32
In the expression: B
In an equation for `maxBound': maxBound = B
When typechecking the code for `maxBound'
in a standalone derived instance for `Bounded (Foo a)':
To see the code I am typechecking, use -ddump-deriv
In the instance declaration for `Bounded (Foo a)'
Failed, modules loaded: none.
```
I suspect that this is also a bug, as it would be perfectly reasonable to have minBound and maxBound for a type such as Foo Int.
A similar deriving fails also for Read class, among those I tried.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.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":"stand-alone deriving sometimes fails for GADTs","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":["GADTs","deriving","mechanism,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following module\r\n\r\n{{{\r\n{-# LANGUAGE GADTs, StandaloneDeriving #-}\r\nmodule Foo where\r\n\r\ndata Foo a where\r\n A, B :: Foo Int\r\n\r\nderiving instance Enum (Foo a)\r\n}}}\r\n\r\nLoading it into GHCi causes the following message:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.0.1 for x86_64-unknown-linux):\r\n maybe_is_tagToEnum_call.extract_constr_Ids\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nIn the case of Bounded instead of Enum in the original code, it does not work either but the error message is more \"even-tempered\":\r\n\r\n{{{\r\nFoo.hs:7:1:\r\n Couldn't match type `a' with `Int'\r\n `a' is a rigid type variable bound by\r\n the instance declaration at Foo.hs:7:32\r\n In the expression: A\r\n In an equation for `minBound': minBound = A\r\n When typechecking the code for `minBound'\r\n in a standalone derived instance for `Bounded (Foo a)':\r\n To see the code I am typechecking, use -ddump-deriv\r\n In the instance declaration for `Bounded (Foo a)'\r\n\r\nFoo.hs:7:1:\r\n Couldn't match type `a' with `Int'\r\n `a' is a rigid type variable bound by\r\n the instance declaration at Foo.hs:7:32\r\n In the expression: B\r\n In an equation for `maxBound': maxBound = B\r\n When typechecking the code for `maxBound'\r\n in a standalone derived instance for `Bounded (Foo a)':\r\n To see the code I am typechecking, use -ddump-deriv\r\n In the instance declaration for `Bounded (Foo a)'\r\nFailed, modules loaded: none.\r\n}}}\r\n\r\nI suspect that this is also a bug, as it would be perfectly reasonable to have minBound and maxBound for a type such as Foo Int.\r\n\r\nA similar deriving fails also for Read class, among those I tried. \r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4529Deriving Data does not work for attached code2019-07-07T18:58:32ZmitarDeriving Data does not work for attached codeFor attached code I get this error:
```
Test2.hs:19:48:
Could not deduce (Real r, Random r)
from the context (Data r, Typeable1 t)
arising from a use of `f'
Possible fix:
add (Real r, Random r) to the context o...For attached code I get this error:
```
Test2.hs:19:48:
Could not deduce (Real r, Random r)
from the context (Data r, Typeable1 t)
arising from a use of `f'
Possible fix:
add (Real r, Random r) to the context of
the type signature for `dataCast1'
or the instance declaration
In the first argument of `gcast1', namely `f'
In the expression: gcast1 f
In an equation for `dataCast1': dataCast1 f = gcast1 f
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mmitar@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Deriving Data does not work for attached code","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["mmitar@gmail.com"],"type":"Bug","description":"For attached code I get this error:\r\n\r\n{{{\r\nTest2.hs:19:48:\r\n Could not deduce (Real r, Random r)\r\n from the context (Data r, Typeable1 t)\r\n arising from a use of `f'\r\n Possible fix:\r\n add (Real r, Random r) to the context of\r\n the type signature for `dataCast1'\r\n or the instance declaration\r\n In the first argument of `gcast1', namely `f'\r\n In the expression: gcast1 f\r\n In an equation for `dataCast1': dataCast1 f = gcast1 f\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4798Make HsIf more polymorphic with RebindableSyntax2019-07-07T18:58:30ZnschMake HsIf more polymorphic with RebindableSyntaxCurrently, ifThenElse is typed this way:
```
ifThenElse :: pred_ty -> b_ty -> b_ty -> res_ty
```
I propose to change this to:
```
ifThenElse :: pred_ty -> b1_ty -> b2_ty -> res_ty
```
to support expressions like this:
```
ifThenElse...Currently, ifThenElse is typed this way:
```
ifThenElse :: pred_ty -> b_ty -> b_ty -> res_ty
```
I propose to change this to:
```
ifThenElse :: pred_ty -> b1_ty -> b2_ty -> res_ty
```
to support expressions like this:
```
ifThenElse :: Maybe a -> (a -> b) -> b -> b
ifThenElse (Just a) f _ = f a
ifThenElse Nothing _ e = e
example :: String
example = if Just 2
then \v -> show v
else "No value"
```
The fix is very simple and just one more line to add to the typechecker. Patch is attached.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.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":"Make HsIf more polymorphic with RebindableSyntax","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"nsch"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently, ifThenElse is typed this way:\r\n\r\n{{{\r\nifThenElse :: pred_ty -> b_ty -> b_ty -> res_ty\r\n}}}\r\n\r\nI propose to change this to:\r\n\r\n{{{\r\nifThenElse :: pred_ty -> b1_ty -> b2_ty -> res_ty\r\n}}}\r\n\r\nto support expressions like this:\r\n\r\n{{{\r\nifThenElse :: Maybe a -> (a -> b) -> b -> b\r\nifThenElse (Just a) f _ = f a\r\nifThenElse Nothing _ e = e\r\n\r\nexample :: String\r\nexample = if Just 2\r\n then \\v -> show v\r\n else \"No value\"\r\n}}}\r\n\r\nThe fix is very simple and just one more line to add to the typechecker. Patch is attached.","type_of_failure":"OtherFailure","blocking":[]} -->nschnschhttps://gitlab.haskell.org/ghc/ghc/-/issues/4801Typechecker performance regression 6.12 -> 7.0.12019-07-07T18:58:29ZSimon MarlowTypechecker performance regression 6.12 -> 7.0.1The attached module is a smaller version of the example in #4505.
With GHC 6.12.3 it takes 4s to compile (x86_64/Linux), whereas with 7.0.1 it takes 282s. HEAD seems about the same as 7.0.1.
<details><summary>Trac metadata</summary>
|...The attached module is a smaller version of the example in #4505.
With GHC 6.12.3 it takes 4s to compile (x86_64/Linux), whereas with 7.0.1 it takes 282s. HEAD seems about the same as 7.0.1.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Typechecker performance regression 6.12 -> 7.0.1","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached module is a smaller version of the example in #4505.\r\n\r\nWith GHC 6.12.3 it takes 4s to compile (x86_64/Linux), whereas with 7.0.1 it takes 282s. HEAD seems about the same as 7.0.1.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/4856Performance regression in the type checker regression for GADTs and type fami...2019-07-07T18:58:11ZManuel M T ChakravartyPerformance regression in the type checker regression for GADTs and type familiesThe GHC 7.0.2 RC1 shows poor performance when compiling `Data.Array.Accelerate`. In particular, to type check a particular module, GHC 7.02 takes several minutes, while GHC's resident memory grows to 350MB. In contrast, GHC 6.12.3 compil...The GHC 7.0.2 RC1 shows poor performance when compiling `Data.Array.Accelerate`. In particular, to type check a particular module, GHC 7.02 takes several minutes, while GHC's resident memory grows to 350MB. In contrast, GHC 6.12.3 compiles the same module in a few seconds.
How to reproduce the problem:
1. Download the latest version of `Data.Array.Accelerate` with darcs from [http://code.haskell.org/accelerate/](http://code.haskell.org/accelerate/)
1. Change directory to the new `accelerate` darcs repo.
1. Invoke GHCi as `ghci -Iinclude`.
1. Issue the GHCi command: `:l Data/Array/Accelerate/Smart.hs`
You will notice that `Data.Arra.Accelerate.Array.Sugar`, which is heavy in type classes and type families, already requires a noticeable time to compile — this is already a performance regression from 6.12.3. The module `Data.Array.Accelerate.Smart` requires an even much longer time to compile.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | ValidProgramRejected |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Performance regression in the type checker regression for GADTs and type families","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The GHC 7.0.2 RC1 shows poor performance when compiling `Data.Array.Accelerate`. In particular, to type check a particular module, GHC 7.02 takes several minutes, while GHC's resident memory grows to 350MB. In contrast, GHC 6.12.3 compiles the same module in a few seconds.\r\n\r\nHow to reproduce the problem:\r\n\r\n 0. Download the latest version of `Data.Array.Accelerate` with darcs from [http://code.haskell.org/accelerate/]\r\n 1. Change directory to the new `accelerate` darcs repo.\r\n 2. Invoke GHCi as `ghci -Iinclude`.\r\n 3. Issue the GHCi command: `:l Data/Array/Accelerate/Smart.hs`\r\n\r\nYou will notice that `Data.Arra.Accelerate.Array.Sugar`, which is heavy in type classes and type families, already requires a noticeable time to compile — this is already a performance regression from 6.12.3. The module `Data.Array.Accelerate.Smart` requires an even much longer time to compile.","type_of_failure":"ValidProgramRejected","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4921report ambiguous type variables more consistently2019-07-07T18:57:55ZSaizanreport ambiguous type variables more consistently```
{-# LANGUAGE MultiParamTypeClasses #-}
module Amb where ...```
{-# LANGUAGE MultiParamTypeClasses #-}
module Amb where
class C a b where
f :: (a,b)
instance C Int Char where
f = undefined
{-
x = fst f
/home/saizan/snippets/Amb.hs:7:8:
Ambiguous type variables `a', `b' in the constraint:
`C a b'
arising from a use of `f' at /home/saizan/snippets/Amb.hs:7:8
Possible cause: the monomorphism restriction applied to the following:
x :: a (bound at /home/saizan/snippets/Amb.hs:7:0)
Probable fix: give these definition(s) an explicit type signature
or use -XNoMonomorphismRestriction
Failed, modules loaded: none.
-}
{-
y = fst f :: Int
/home/saizan/snippets/Amb.hs:21:8:
No instance for (C Int b)
arising from a use of `f' at /home/saizan/snippets/Amb.hs:21:8
Possible fix: add an instance declaration for (C Int b)
In the first argument of `fst', namely `f'
In the expression: fst f :: Int
In the definition of `y': y = fst f :: Int
Failed, modules loaded: none.
-}
```
Both x and y have the same problem, there isn't enough type information to let the typechecker decide on an instance, so it seems they should produce similar error messages.
In particular, the error for y is quite confusing since it can be reasonably interpreted as saying there's no type b for which there's an instance C Int b, which in fact is not true, so i think explicitly mentioning the ambiguity like in the first message would help many to understand the problem better.
I can see though that an "instance C Int b" could make sense, more often than C a b, so maybe "Possible fix: add an instance declaration for (C Int b)" should be conserved, even if it still has the problem of expressing that the second argument needs to be a variable.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.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":"report ambiguous type variables more consistently","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"{{{\r\n{-# LANGUAGE MultiParamTypeClasses #-} \r\nmodule Amb where \r\n \r\nclass C a b where \r\n f :: (a,b) \r\n \r\ninstance C Int Char where \r\n f = undefined \r\n \r\n{- \r\nx = fst f \r\n/home/saizan/snippets/Amb.hs:7:8: \r\n Ambiguous type variables `a', `b' in the constraint: \r\n `C a b' \r\n arising from a use of `f' at /home/saizan/snippets/Amb.hs:7:8 \r\n Possible cause: the monomorphism restriction applied to the following: \r\n x :: a (bound at /home/saizan/snippets/Amb.hs:7:0) \r\n Probable fix: give these definition(s) an explicit type signature \r\n or use -XNoMonomorphismRestriction \r\nFailed, modules loaded: none. \r\n-} \r\n \r\n{- \r\ny = fst f :: Int \r\n \r\n/home/saizan/snippets/Amb.hs:21:8: \r\n No instance for (C Int b) \r\n arising from a use of `f' at /home/saizan/snippets/Amb.hs:21:8 \r\n Possible fix: add an instance declaration for (C Int b) \r\n In the first argument of `fst', namely `f' \r\n In the expression: fst f :: Int \r\n In the definition of `y': y = fst f :: Int \r\nFailed, modules loaded: none. \r\n-}\r\n}}}\r\n\r\nBoth x and y have the same problem, there isn't enough type information to let the typechecker decide on an instance, so it seems they should produce similar error messages.\r\n\r\nIn particular, the error for y is quite confusing since it can be reasonably interpreted as saying there's no type b for which there's an instance C Int b, which in fact is not true, so i think explicitly mentioning the ambiguity like in the first message would help many to understand the problem better.\r\n\r\nI can see though that an \"instance C Int b\" could make sense, more often than C a b, so maybe \"Possible fix: add an instance declaration for (C Int b)\" should be conserved, even if it still has the problem of expressing that the second argument needs to be a variable.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/4935New type error in GHC 7.1 with TypeFamilies, Rank2Types2019-07-07T18:57:51Zpatrick_premontNew type error in GHC 7.1 with TypeFamilies, Rank2TypesThe following produces a type error with ghc-7.1.20110126. No error is reported by ghc-7.0.1.
```
condBug.lhs:48:29:
Could not deduce (a ~ CondV c a (f a))
from the context (TBool c, Functor f)
bound by the type signature ...The following produces a type error with ghc-7.1.20110126. No error is reported by ghc-7.0.1.
```
condBug.lhs:48:29:
Could not deduce (a ~ CondV c a (f a))
from the context (TBool c, Functor f)
bound by the type signature for
condMap :: (TBool c, Functor f) =>
(a -> b) -> Cond c f a -> Cond c f b
at condBug.lhs:48:3-40
or from (c ~ TFalse)
bound by a type expected by the context:
c ~ TFalse => CondV c a (f a) -> b
at condBug.lhs:48:24-40
`a' is a rigid type variable bound by
the type signature for
condMap :: (TBool c, Functor f) =>
(a -> b) -> Cond c f a -> Cond c f b
at condBug.lhs:48:3
Expected type: CondV c a (f a) -> b
Actual type: a -> b
In the first argument of `cond', namely `g'
In the expression: cond g (fmap g) n
```
```
> {-# LANGUAGE TypeFamilies, Rank2Types, ScopedTypeVariables #-}
> import Control.Applicative
> data TFalse
> data TTrue
> data Tagged b a = Tagged {at :: a}
> type At b = forall a. Tagged b a -> a
> class TBool b where onTBool :: (b ~ TFalse => c) -> (b ~ TTrue => c) -> Tagged b c
> instance TBool TFalse where onTBool f _ = Tagged $ f
> instance TBool TTrue where onTBool _ t = Tagged $ t
> type family CondV c f t
> type instance CondV TFalse f t = f
> type instance CondV TTrue f t = t
> newtype Cond c f a = Cond {getCond :: CondV c a (f a)}
> cond :: forall c f a g. (TBool c, Functor g) => (c ~ TFalse => g a) -> (c ~ TTrue => g (f a)) -> g (Cond c f a)
> cond f t = (at :: At c) $ onTBool (fmap Cond f) (fmap Cond t)
> condMap :: (TBool c, Functor f) => (a -> b) -> Cond c f a -> Cond c f b
> condMap g (Cond n) = cond g (fmap g) n
> main = undefined
```
The type error seems inappropriate. Given the defintion of 'CondV', and the 'c \~ TFalse'
available form the context, shouldn't the compiler see that 'CondV c a (f a) \~ a' ?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.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":"New type error in GHC 7.1 with TypeFamilies, Rank2Types","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following produces a type error with ghc-7.1.20110126. No error is reported by ghc-7.0.1.\r\n\r\n{{{\r\ncondBug.lhs:48:29:\r\n Could not deduce (a ~ CondV c a (f a))\r\n from the context (TBool c, Functor f)\r\n bound by the type signature for\r\n condMap :: (TBool c, Functor f) =>\r\n (a -> b) -> Cond c f a -> Cond c f b\r\n at condBug.lhs:48:3-40\r\n or from (c ~ TFalse)\r\n bound by a type expected by the context:\r\n c ~ TFalse => CondV c a (f a) -> b\r\n at condBug.lhs:48:24-40\r\n `a' is a rigid type variable bound by\r\n the type signature for\r\n condMap :: (TBool c, Functor f) =>\r\n (a -> b) -> Cond c f a -> Cond c f b\r\n at condBug.lhs:48:3\r\n Expected type: CondV c a (f a) -> b\r\n Actual type: a -> b\r\n In the first argument of `cond', namely `g'\r\n In the expression: cond g (fmap g) n\r\n}}}\r\n\r\n{{{\r\n\r\n> {-# LANGUAGE TypeFamilies, Rank2Types, ScopedTypeVariables #-}\r\n\r\n> import Control.Applicative\r\n\r\n> data TFalse\r\n> data TTrue\r\n\r\n> data Tagged b a = Tagged {at :: a}\r\n> type At b = forall a. Tagged b a -> a\r\n\r\n> class TBool b where onTBool :: (b ~ TFalse => c) -> (b ~ TTrue => c) -> Tagged b c\r\n> instance TBool TFalse where onTBool f _ = Tagged $ f\r\n> instance TBool TTrue where onTBool _ t = Tagged $ t\r\n\r\n> type family CondV c f t\r\n> type instance CondV TFalse f t = f\r\n> type instance CondV TTrue f t = t\r\n\r\n> newtype Cond c f a = Cond {getCond :: CondV c a (f a)}\r\n> cond :: forall c f a g. (TBool c, Functor g) => (c ~ TFalse => g a) -> (c ~ TTrue => g (f a)) -> g (Cond c f a)\r\n> cond f t = (at :: At c) $ onTBool (fmap Cond f) (fmap Cond t)\r\n> condMap :: (TBool c, Functor f) => (a -> b) -> Cond c f a -> Cond c f b\r\n> condMap g (Cond n) = cond g (fmap g) n\r\n \r\n> main = undefined\r\n\r\n}}}\r\n\r\nThe type error seems inappropriate. Given the defintion of 'CondV', and the 'c ~ TFalse'\r\navailable form the context, shouldn't the compiler see that 'CondV c a (f a) ~ a' ?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4940Bad error message using poly pat bind with MonoPatBinds2019-07-07T18:57:46ZbatterseapowerBad error message using poly pat bind with MonoPatBindsThis program:
```
foo :: a -> a
bar :: a -> a
(foo, bar) = (\x -> x, \y -> y)
main = print $ foo $ bar 1
```
Is trying to pattern-bind a polymorphic function. The error message is dreadful:
```
/Users/mbolingbroke/Junk/PolyPatBinds.h...This program:
```
foo :: a -> a
bar :: a -> a
(foo, bar) = (\x -> x, \y -> y)
main = print $ foo $ bar 1
```
Is trying to pattern-bind a polymorphic function. The error message is dreadful:
```
/Users/mbolingbroke/Junk/PolyPatBinds.hs:5:15:
Couldn't match expected type `t -> t1'
with actual type `forall a. a -> a'
The lambda expression `\ x -> x' has one argument one argument,
but its type `forall a. a -> a' has none
In the expression: \ x -> x
In the expression: (\ x -> x, \ y -> y)
```
The issues are:
1. It repeats itself: "one argument one argument"
1. It is patently incorrect: the type forall a. a -\> a DOES have one argument in the standard nomenclature
1. It does not point the user towards the fix (-XNoMonoPatBinds)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.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":"Bad error message using poly pat bind with MonoPatBinds","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"This program:\r\n\r\n{{{\r\nfoo :: a -> a\r\nbar :: a -> a\r\n(foo, bar) = (\\x -> x, \\y -> y)\r\n\r\nmain = print $ foo $ bar 1\r\n}}}\r\n\r\nIs trying to pattern-bind a polymorphic function. The error message is dreadful:\r\n\r\n{{{\r\n/Users/mbolingbroke/Junk/PolyPatBinds.hs:5:15:\r\n Couldn't match expected type `t -> t1'\r\n with actual type `forall a. a -> a'\r\n The lambda expression `\\ x -> x' has one argument one argument,\r\n but its type `forall a. a -> a' has none\r\n In the expression: \\ x -> x\r\n In the expression: (\\ x -> x, \\ y -> y)\r\n}}}\r\n\r\nThe issues are:\r\n\r\n1. It repeats itself: \"one argument one argument\"\r\n2. It is patently incorrect: the type forall a. a -> a DOES have one argument in the standard nomenclature\r\n3. It does not point the user towards the fix (-XNoMonoPatBinds)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4949TH typechecking regression2019-07-07T18:57:39ZIan Lynagh <igloo@earth.li>TH typechecking regressionThe 7.0 branch (and HEAD) behaves differently to 7.0.1 on this modules:
```
{-# LANGUAGE TemplateHaskell #-}
module Foo where
import Language.Haskell.TH
x :: Int
x = let args = [| show $(varE (mkName "x")) |]
in undefined
```
1. ...The 7.0 branch (and HEAD) behaves differently to 7.0.1 on this modules:
```
{-# LANGUAGE TemplateHaskell #-}
module Foo where
import Language.Haskell.TH
x :: Int
x = let args = [| show $(varE (mkName "x")) |]
in undefined
```
1. 0.1 accepted it, while we now get:
```
Foo.hs:7:19:
Ambiguous type variable `a0' in the constraint:
(Show a0) arising from a use of `show'
Probable fix: add a type signature that fixes these type variable(s)
In the Template Haskell quotation [| show ($(varE (mkName "x"))) |]
In the expression: [| show ($(varE (mkName "x"))) |]
In an equation for `args': args = [| show ($(varE (mkName "x"))) |]
```
This affects these packages:
```
CCA
Printf-TH
grammar-combinators
hacanon-light
hamlet
rowrecord
th-lift
web-routes-quasi
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"TH typechecking regression","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The 7.0 branch (and HEAD) behaves differently to 7.0.1 on this modules:\r\n{{{\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule Foo where\r\n\r\nimport Language.Haskell.TH\r\n\r\nx :: Int\r\nx = let args = [| show $(varE (mkName \"x\")) |]\r\n in undefined\r\n}}}\r\n\r\n7.0.1 accepted it, while we now get:\r\n{{{\r\nFoo.hs:7:19:\r\n Ambiguous type variable `a0' in the constraint:\r\n (Show a0) arising from a use of `show'\r\n Probable fix: add a type signature that fixes these type variable(s)\r\n In the Template Haskell quotation [| show ($(varE (mkName \"x\"))) |]\r\n In the expression: [| show ($(varE (mkName \"x\"))) |]\r\n In an equation for `args': args = [| show ($(varE (mkName \"x\"))) |]\r\n}}}\r\n\r\nThis affects these packages:\r\n{{{\r\nCCA\r\nPrintf-TH\r\ngrammar-combinators\r\nhacanon-light\r\nhamlet\r\nrowrecord\r\nth-lift\r\nweb-routes-quasi\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/4952Typechecking regression2019-07-07T18:57:39ZIan Lynagh <igloo@earth.li>Typechecking regression1. 0.1 accepts this module (cut down from hashed-storage-0.5.4):
```
{-# LANGUAGE UndecidableInstances,
MultiParamTypeClasses,
KindSignatures,
FlexibleInstances,
FunctionalDependencies...1. 0.1 accepts this module (cut down from hashed-storage-0.5.4):
```
{-# LANGUAGE UndecidableInstances,
MultiParamTypeClasses,
KindSignatures,
FlexibleInstances,
FunctionalDependencies #-}
module Storage.Hashed.Monad () where
class Monad m => TreeRO m where
withDirectory :: (MonadError e m) => Int -> m a -> m a
expandTo :: (MonadError e m) => Int -> m Int
instance (Monad m, MonadError e m) => TreeRO (M m) where
expandTo = undefined
withDirectory dir _ = do
_ <- expandTo dir
undefined
data M (m :: * -> *) a
instance Monad m => Monad (M m) where
(>>=) = undefined
return = undefined
instance MonadError e m => MonadError e (M m)
class Monad m => MonadError e m | m -> e
```
but 7.0 branch says:
```
[1 of 1] Compiling Storage.Hashed.Monad ( Storage/Hashed/Monad.hs, interpreted )
Storage/Hashed/Monad.hs:17:12:
Could not deduce (MonadError e1 m) arising from a use of `expandTo'
from the context (Monad m, MonadError e m)
bound by the instance declaration
at Storage/Hashed/Monad.hs:14:10-50
or from (MonadError e1 (M m))
bound by the type signature for
withDirectory :: MonadError e1 (M m) => Int -> M m a -> M m a
at Storage/Hashed/Monad.hs:(16,5)-(18,15)
Possible fix:
add (MonadError e1 m) to the context of
the type signature for
withDirectory :: MonadError e1 (M m) => Int -> M m a -> M m a
or the instance declaration
In a stmt of a 'do' expression: _ <- expandTo dir
In the expression:
do { _ <- expandTo dir;
undefined }
In an equation for `withDirectory':
withDirectory dir _
= do { _ <- expandTo dir;
undefined }
Failed, modules loaded: none.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Typechecking regression","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"7.0.1 accepts this module (cut down from hashed-storage-0.5.4):\r\n{{{\r\n{-# LANGUAGE UndecidableInstances,\r\n MultiParamTypeClasses,\r\n KindSignatures,\r\n FlexibleInstances,\r\n FunctionalDependencies #-}\r\n\r\nmodule Storage.Hashed.Monad () where\r\n\r\nclass Monad m => TreeRO m where\r\n withDirectory :: (MonadError e m) => Int -> m a -> m a\r\n expandTo :: (MonadError e m) => Int -> m Int\r\n\r\ninstance (Monad m, MonadError e m) => TreeRO (M m) where\r\n expandTo = undefined\r\n withDirectory dir _ = do\r\n _ <- expandTo dir\r\n undefined\r\n\r\ndata M (m :: * -> *) a\r\n\r\ninstance Monad m => Monad (M m) where\r\n (>>=) = undefined\r\n return = undefined\r\n\r\ninstance MonadError e m => MonadError e (M m)\r\n\r\nclass Monad m => MonadError e m | m -> e\r\n}}}\r\nbut 7.0 branch says:\r\n{{{\r\n[1 of 1] Compiling Storage.Hashed.Monad ( Storage/Hashed/Monad.hs, interpreted )\r\n\r\nStorage/Hashed/Monad.hs:17:12:\r\n Could not deduce (MonadError e1 m) arising from a use of `expandTo'\r\n from the context (Monad m, MonadError e m)\r\n bound by the instance declaration\r\n at Storage/Hashed/Monad.hs:14:10-50\r\n or from (MonadError e1 (M m))\r\n bound by the type signature for\r\n withDirectory :: MonadError e1 (M m) => Int -> M m a -> M m a\r\n at Storage/Hashed/Monad.hs:(16,5)-(18,15)\r\n Possible fix:\r\n add (MonadError e1 m) to the context of\r\n the type signature for\r\n withDirectory :: MonadError e1 (M m) => Int -> M m a -> M m a\r\n or the instance declaration\r\n In a stmt of a 'do' expression: _ <- expandTo dir\r\n In the expression:\r\n do { _ <- expandTo dir;\r\n undefined }\r\n In an equation for `withDirectory':\r\n withDirectory dir _\r\n = do { _ <- expandTo dir;\r\n undefined }\r\nFailed, modules loaded: none.\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/4966Type checking regression2022-01-13T11:32:31ZIan Lynagh <igloo@earth.li>Type checking regressionThis module:
```
{-# LANGUAGE EmptyDataDecls #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE OverlappingInstances #-}
module HTk.Toolkit.TreeList (getObjectFromTreeList) where
class Eq c => CI...This module:
```
{-# LANGUAGE EmptyDataDecls #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE OverlappingInstances #-}
module HTk.Toolkit.TreeList (getObjectFromTreeList) where
class Eq c => CItem c
data StateEntry a = StateEntry (TreeListObject a)
a -- Comment this 'a' out and it type checks
deriving Eq
getObjectFromTreeList :: CItem a => [StateEntry a] -> Bool
getObjectFromTreeList state = (head state == head state)
data CItem a => TreeListObject a
instance CItem a => Eq (TreeListObject a)
class GUIObject w where
toGUIObject :: w -> GUIOBJECT
instance GUIObject w => Eq w where
w1 == w2 = toGUIObject w1 == toGUIObject w2
data GUIOBJECT
instance Eq GUIOBJECT where
(==) = undefined
(/=) = undefined
```
is accepted by 7.0.1, but not by 7.0-branch or HEAD:
```
Q.hs:16:43:
Could not deduce (GUIObject a) arising from a use of `=='
from the context (CItem a)
bound by the type signature for
getObjectFromTreeList :: CItem a => [StateEntry a] -> Bool
at Q.hs:16:1-56
Possible fix:
add (GUIObject a) to the context of
the type signature for
getObjectFromTreeList :: CItem a => [StateEntry a] -> Bool
In the expression: (head state == head state)
In an equation for `getObjectFromTreeList':
getObjectFromTreeList state = (head state == head state)
```
If you comment out the `a` then it is accepted by all 3.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Type checking regression","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.0.2","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This module:\r\n{{{\r\n{-# LANGUAGE EmptyDataDecls #-}\r\n{-# LANGUAGE FlexibleInstances #-}\r\n{-# LANGUAGE UndecidableInstances #-}\r\n{-# LANGUAGE OverlappingInstances #-}\r\n\r\nmodule HTk.Toolkit.TreeList (getObjectFromTreeList) where\r\n\r\nclass Eq c => CItem c\r\n\r\ndata StateEntry a = StateEntry (TreeListObject a)\r\n a -- Comment this 'a' out and it type checks\r\n deriving Eq\r\n\r\ngetObjectFromTreeList :: CItem a => [StateEntry a] -> Bool\r\ngetObjectFromTreeList state = (head state == head state)\r\n\r\ndata CItem a => TreeListObject a\r\n\r\ninstance CItem a => Eq (TreeListObject a)\r\n\r\nclass GUIObject w where\r\n toGUIObject :: w -> GUIOBJECT\r\n\r\ninstance GUIObject w => Eq w where\r\n w1 == w2 = toGUIObject w1 == toGUIObject w2\r\n\r\ndata GUIOBJECT\r\n\r\ninstance Eq GUIOBJECT where\r\n (==) = undefined\r\n (/=) = undefined\r\n}}}\r\nis accepted by 7.0.1, but not by 7.0-branch or HEAD:\r\n{{{\r\nQ.hs:16:43:\r\n Could not deduce (GUIObject a) arising from a use of `=='\r\n from the context (CItem a)\r\n bound by the type signature for\r\n getObjectFromTreeList :: CItem a => [StateEntry a] -> Bool\r\n at Q.hs:16:1-56\r\n Possible fix:\r\n add (GUIObject a) to the context of\r\n the type signature for\r\n getObjectFromTreeList :: CItem a => [StateEntry a] -> Bool\r\n In the expression: (head state == head state)\r\n In an equation for `getObjectFromTreeList':\r\n getObjectFromTreeList state = (head state == head state)\r\n}}}\r\nIf you comment out the `a` then it is accepted by all 3.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/5007"deriving" seems to ignore class context for a type family2019-07-07T18:57:21Zjkff"deriving" seems to ignore class context for a type family```
class Foo a where
data Bar a :: *
class (Show (Bar a)) => Qux a
data (Qux a) => Xyzzy a = Xyzzy (Bar a) deriving Show
```
Here I get the following error:
```
No instance for (Show (Bar a))
arising from the 'deriving' c...```
class Foo a where
data Bar a :: *
class (Show (Bar a)) => Qux a
data (Qux a) => Xyzzy a = Xyzzy (Bar a) deriving Show
```
Here I get the following error:
```
No instance for (Show (Bar a))
arising from the 'deriving' clause of a data type declaration
Possible fix:
add an instance declaration for (Show (Bar a))
or use a standalone 'deriving instance' declaration,
so you can specify the instance context yourself
When deriving the instance for (Show (Xyzzy a))
```
Curiously, I get the same error even if I add ", Show (Bar a)" to the context of "Xyzzy".
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.2 |
| 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":"\"deriving\" seems to ignore class context for a type family","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.2","keywords":["classes,","contexts,","datatype","deriving","families,","type"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nclass Foo a where\r\n data Bar a :: *\r\n\r\nclass (Show (Bar a)) => Qux a\r\ndata (Qux a) => Xyzzy a = Xyzzy (Bar a) deriving Show\r\n}}}\r\n\r\nHere I get the following error:\r\n{{{\r\n No instance for (Show (Bar a))\r\n arising from the 'deriving' clause of a data type declaration\r\n Possible fix:\r\n add an instance declaration for (Show (Bar a))\r\n or use a standalone 'deriving instance' declaration,\r\n so you can specify the instance context yourself\r\n When deriving the instance for (Show (Xyzzy a))\r\n}}}\r\n\r\nCuriously, I get the same error even if I add \", Show (Bar a)\" to the context of \"Xyzzy\".","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/5012haskell 98 program does not typecheck when compiled with -XTypeFamilies2019-07-07T18:57:20ZDaniel Gorínhaskell 98 program does not typecheck when compiled with -XTypeFamiliesConsider the following valid Haskell 98 function:
```
f x =
do let apply p r = mapM p (r x)
a <- apply id fst
b <- apply return snd
return (a ++ b)
```
It compiles fine with both ghc 6.12.x and ghc 7. However, if I...Consider the following valid Haskell 98 function:
```
f x =
do let apply p r = mapM p (r x)
a <- apply id fst
b <- apply return snd
return (a ++ b)
```
It compiles fine with both ghc 6.12.x and ghc 7. However, if I add the -XTypeFamilies flag to ghc 7 it is rejected with:
```
mono.hs:5:17:
Occurs check: cannot construct the infinite type: a0 = m0 a0
Expected type: m0 a0 -> m0 a0
Actual type: m0 a0 -> m0 (m0 a0)
In the first argument of `apply', namely `return'
In a stmt of a 'do' expression: b <- apply return snd
```
If one adds a type signature, the error message gets more intimidating.
A project of mine uses Type Families in some modules so TypeFamilies is listed as an extension in cabal's configuration file; therefore, it is being passed to every module. That is how I stumbled upon this problem.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.2 |
| 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":"haskell 98 program does not typecheck when compiled with -XTypeFamilies","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following valid Haskell 98 function:\r\n\r\n{{{\r\nf x =\r\n do let apply p r = mapM p (r x)\r\n a <- apply id fst\r\n b <- apply return snd\r\n return (a ++ b)\r\n}}}\r\n\r\nIt compiles fine with both ghc 6.12.x and ghc 7. However, if I add the -XTypeFamilies flag to ghc 7 it is rejected with:\r\n\r\n{{{\r\nmono.hs:5:17:\r\n Occurs check: cannot construct the infinite type: a0 = m0 a0\r\n Expected type: m0 a0 -> m0 a0\r\n Actual type: m0 a0 -> m0 (m0 a0)\r\n In the first argument of `apply', namely `return'\r\n In a stmt of a 'do' expression: b <- apply return snd\r\n}}}\r\n\r\nIf one adds a type signature, the error message gets more intimidating.\r\n\r\nA project of mine uses Type Families in some modules so TypeFamilies is listed as an extension in cabal's configuration file; therefore, it is being passed to every module. That is how I stumbled upon this problem.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5015Can't unsafeCoerce a GADT with a coercion2019-07-07T18:57:20ZToRACan't unsafeCoerce a GADT with a coercion```
type family Blah a
type instance Blah Int = Int
data E where
E :: (Blah a ~ Int) => a -> E
```
```
*Example Unsafe.Coerce GHC.Prim> (unsafeCoerce E) :: Any
<interactive>:1:15:
Couldn't match type `Blah a0' with `Int'
In ...```
type family Blah a
type instance Blah Int = Int
data E where
E :: (Blah a ~ Int) => a -> E
```
```
*Example Unsafe.Coerce GHC.Prim> (unsafeCoerce E) :: Any
<interactive>:1:15:
Couldn't match type `Blah a0' with `Int'
In the first argument of `unsafeCoerce', namely `E'
In the expression: (unsafeCoerce E) :: Any
In an equation for `it': it = (unsafeCoerce E) :: Any
```
This also doesn't work with less dangerous operators, like seq:
```
*Example Unsafe.Coerce GHC.Prim> (id E) `seq` ()
<interactive>:1:5:
Couldn't match type `Blah a0' with `Int'
In the first argument of `id', namely `E'
In the first argument of `seq', namely `(id E)'
In the expression: (id E) `seq` ()
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.2 |
| 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":"Can't unsafeCoerce a GADT with a coercion","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\ntype family Blah a \r\ntype instance Blah Int = Int\r\ndata E where\r\n E :: (Blah a ~ Int) => a -> E\r\n}}}\r\n\r\n{{{\r\n*Example Unsafe.Coerce GHC.Prim> (unsafeCoerce E) :: Any\r\n\r\n<interactive>:1:15:\r\n Couldn't match type `Blah a0' with `Int'\r\n In the first argument of `unsafeCoerce', namely `E'\r\n In the expression: (unsafeCoerce E) :: Any\r\n In an equation for `it': it = (unsafeCoerce E) :: Any\r\n}}}\r\n\r\nThis also doesn't work with less dangerous operators, like seq:\r\n\r\n{{{\r\n*Example Unsafe.Coerce GHC.Prim> (id E) `seq` ()\r\n\r\n<interactive>:1:5:\r\n Couldn't match type `Blah a0' with `Int'\r\n In the first argument of `id', namely `E'\r\n In the first argument of `seq', namely `(id E)'\r\n In the expression: (id E) `seq` ()\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5030Slow type checking of type-level computation heavy code.2019-07-07T18:57:15ZSerguey ZefirovSlow type checking of type-level computation heavy code.It seems we encountered a highly non-linear complexity in type checking.
I attached a "simple" program that produces the effect.
The time needed to load complete file in ghci depending on number of lines in longCompilingProgram:
- 4 l...It seems we encountered a highly non-linear complexity in type checking.
I attached a "simple" program that produces the effect.
The time needed to load complete file in ghci depending on number of lines in longCompilingProgram:
- 4 lines - 2 secs,
- 8 lines - 10 secs,
- 12 lines - 27 secs,
- 16 lines - 59 secs.
time = 0,0156lines\^3\^ - 0,0937lines\^2\^ + 1,375lines - 3
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.2 |
| 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":"Slow type checking of type-level computation heavy code.","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It seems we encountered a highly non-linear complexity in type checking.\r\n\r\nI attached a \"simple\" program that produces the effect.\r\n\r\nThe time needed to load complete file in ghci depending on number of lines in longCompilingProgram:\r\n * 4 lines - 2 secs,\r\n * 8 lines - 10 secs,\r\n * 12 lines - 27 secs,\r\n * 16 lines - 59 secs.\r\n\r\ntime = 0,0156lines^3^ - 0,0937lines^2^ + 1,375lines - 3\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/5095Incoherent instance for Prelude type class accepted without incoherent instan...2019-07-07T18:56:56ZbrunosoliveiraIncoherent instance for Prelude type class accepted without incoherent instances optionIf we create a new module allowing overlapping instances, flexible instances and undecidable instances we can define a function that selects an incoherent instance for a type class defined in the Prelude. Example:
```
> {-# OPTIONS -XFl...If we create a new module allowing overlapping instances, flexible instances and undecidable instances we can define a function that selects an incoherent instance for a type class defined in the Prelude. Example:
```
> {-# OPTIONS -XFlexibleInstances -XOverlappingInstances -XUndecidableInstances #-}
> module Test where
> instance Show a => Eq a where
> x == y = length (show x) == length (show y)
>
> f :: Show a => a -> a -> Bool
> f x y = x == y
>
> p = f (3 :: Int) 4
```
The instance selected here (tested with GHC 7.0 and 6.12) is the one in this module, even if the instance Eq Int from the Prelude is more specific. If we try to reproduce a similar example using a module other than the Prelude, an incoherent instances error is reported. I believe that, for consistency the same should happen here.7.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/5120inferred type of an implicit parameter rejected (associated type)2019-07-07T18:56:49Zmikkonecnyinferred type of an implicit parameter rejected (associated type)The following module:
```
{-# LANGUAGE ImplicitParams #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE NoMonomorphismRestriction #-}
module Test where
class C t where
type TF t
ttt :: TF t -> t
b :: (C t, ?x :: TF t) => t
b = t...The following module:
```
{-# LANGUAGE ImplicitParams #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE NoMonomorphismRestriction #-}
module Test where
class C t where
type TF t
ttt :: TF t -> t
b :: (C t, ?x :: TF t) => t
b = ttt ?x
```
compiles fine with ghc 6.12.3 but ghc 7.0.3 says:
```
Could not deduce (?x::TF t)
arising from a use of implicit parameter `?x'
from the context (C t, ?x::TF t)
bound by the type signature for b :: (C t, ?x::TF t) => t
at Test.hs:13:1-10
In the first argument of `ttt', namely `?x'
In the expression: ttt ?x
In an equation for `b': b = ttt ?x
```
Moreover, when I comment out the type declaration for b, ghc 7.0.3 compiles it and the inferred type for b is identical to the one that was commented out:
```
*Test> :t b
b :: (C t, ?x::TF t) => t
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.3 |
| 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":"inferred type of an implicit parameter rejected (associated type)","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":["associated","implicit","parameter","type,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following module:\r\n\r\n{{{\r\n{-# LANGUAGE ImplicitParams #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE NoMonomorphismRestriction #-}\r\n\r\nmodule Test where\r\n\r\nclass C t where\r\n type TF t\r\n ttt :: TF t -> t\r\n\r\nb :: (C t, ?x :: TF t) => t\r\nb = ttt ?x \r\n}}}\r\n\r\ncompiles fine with ghc 6.12.3 but ghc 7.0.3 says:\r\n\r\n\r\n{{{\r\n Could not deduce (?x::TF t)\r\n arising from a use of implicit parameter `?x'\r\n from the context (C t, ?x::TF t)\r\n bound by the type signature for b :: (C t, ?x::TF t) => t\r\n at Test.hs:13:1-10\r\n In the first argument of `ttt', namely `?x'\r\n In the expression: ttt ?x\r\n In an equation for `b': b = ttt ?x\r\n}}}\r\n\r\nMoreover, when I comment out the type declaration for b, ghc 7.0.3 compiles it and the inferred type for b is identical to the one that was commented out:\r\n\r\n\r\n{{{\r\n*Test> :t b\r\nb :: (C t, ?x::TF t) => t\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/5130Panic on simple scoped type variable example2019-07-07T18:56:46Zjohn-nowakPanic on simple scoped type variable exampleWhen running GHCi with `-XScopedTypeVariables`:
```
Prelude> (\(x :: a, y :: a) -> [x, "hi"])
ghc: panic! (the 'impossible' happened)
(GHC version 7.0.2 for i386-apple-darwin):
nameModule $dShow{v akk}
```
I'm unsure if this has bee...When running GHCi with `-XScopedTypeVariables`:
```
Prelude> (\(x :: a, y :: a) -> [x, "hi"])
ghc: panic! (the 'impossible' happened)
(GHC version 7.0.2 for i386-apple-darwin):
nameModule $dShow{v akk}
```
I'm unsure if this has been fixed in 7.0.3; apologies if this is an old bug.Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/5217GADT declaration not (yet) handled by Template Haskell2019-07-07T18:56:23ZAshley YakeleyGADT declaration not (yet) handled by Template HaskellCompiling this:
```
{-# LANGUAGE TemplateHaskell, GADTs #-}
module GadtBug where
$([d|data T a where { T :: T Char; }|])
```
gives this:
```
GadtBug.hs:4:23:
GADT declaration not (yet) handled by Template Haskell T :: T Char
```
...Compiling this:
```
{-# LANGUAGE TemplateHaskell, GADTs #-}
module GadtBug where
$([d|data T a where { T :: T Char; }|])
```
gives this:
```
GadtBug.hs:4:23:
GADT declaration not (yet) handled by Template Haskell T :: T Char
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.3 |
| 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":"GADT declaration not (yet) handled by Template Haskell","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compiling this:\r\n{{{\r\n{-# LANGUAGE TemplateHaskell, GADTs #-}\r\nmodule GadtBug where\r\n\r\n$([d|data T a where { T :: T Char; }|])\r\n}}}\r\ngives this:\r\n{{{\r\nGadtBug.hs:4:23:\r\n GADT declaration not (yet) handled by Template Haskell T :: T Char\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/5236Circular functional dependencies cause loop in typechecker2019-07-07T18:56:15ZdimitrisCircular functional dependencies cause loop in typecheckerIn the attached file, a dictionary (Id A B) is rewritten with two
functional dependencies (A -\> B, B -\> A) and two errors are added in our constraint bag (rightfully so), but the new workitem is symmetric (Id B A), goes back in the wor...In the attached file, a dictionary (Id A B) is rewritten with two
functional dependencies (A -\> B, B -\> A) and two errors are added in our constraint bag (rightfully so), but the new workitem is symmetric (Id B A), goes back in the worklist and in the new iteration of the solver we have exactly the same process repeated.
This is a solveInteractWithDepth loop, not a solve_wanteds loop.
I think the right thing to do is in doTopReact: (1) first try to apply functional dependencies, (2) then check if an instance matches, and (3) do a ContinueWith or a Stop but never throw the workitem back in the worklist as happens now. I have to discuss
this with Simon.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonpj@microsoft.com, stevez@cis.upenn.edu |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Circular functional dependencies cause loop in typechecker","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonpj@microsoft.com","stevez@cis.upenn.edu"],"type":"Bug","description":"In the attached file, a dictionary (Id A B) is rewritten with two \r\nfunctional dependencies (A -> B, B -> A) and two errors are added in our constraint bag (rightfully so), but the new workitem is symmetric (Id B A), goes back in the worklist and in the new iteration of the solver we have exactly the same process repeated.\r\n\r\nThis is a solveInteractWithDepth loop, not a solve_wanteds loop.\r\nI think the right thing to do is in doTopReact: (1) first try to apply functional dependencies, (2) then check if an instance matches, and (3) do a ContinueWith or a Stop but never throw the workitem back in the worklist as happens now. I have to discuss \r\nthis with Simon.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5246Duplicate type error messages with implicit parameters2019-07-07T18:56:13ZGhost UserDuplicate type error messages with implicit parametersThe following ill-typed program generates two identical type errors at the same source location:
```
{-# LANGUAGE ImplicitParams #-}
foo :: (?x :: Int) => a
foo = undefined
bar =
let ?x = "hello"
in foo
```
The error messages...The following ill-typed program generates two identical type errors at the same source location:
```
{-# LANGUAGE ImplicitParams #-}
foo :: (?x :: Int) => a
foo = undefined
bar =
let ?x = "hello"
in foo
```
The error messages are:
```
Test.hs:8:8:
Couldn't match type `Int' with `[Char]'
In the expression: foo
In the expression: let ?x = "hello" in foo
In an equation for `bar': bar = let ?x = "hello" in foo
Test.hs:8:8:
Couldn't match type `Int' with `[Char]'
In the expression: foo
In the expression: let ?x = "hello" in foo
In an equation for `bar': bar = let ?x = "hello" in foo
```
Obviously, it should only print this error once. I encountered this in a larger program where it meant I got *eight* identical type errors at the same source position!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.3 |
| 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":"Duplicate type error messages with implicit parameters","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following ill-typed program generates two identical type errors at the same source location:\r\n\r\n{{{\r\n{-# LANGUAGE ImplicitParams #-}\r\n\r\nfoo :: (?x :: Int) => a\r\nfoo = undefined\r\n\r\nbar =\r\n let ?x = \"hello\"\r\n in foo\r\n}}}\r\n\r\nThe error messages are:\r\n\r\n{{{\r\nTest.hs:8:8:\r\n Couldn't match type `Int' with `[Char]'\r\n In the expression: foo\r\n In the expression: let ?x = \"hello\" in foo\r\n In an equation for `bar': bar = let ?x = \"hello\" in foo\r\n\r\nTest.hs:8:8:\r\n Couldn't match type `Int' with `[Char]'\r\n In the expression: foo\r\n In the expression: let ?x = \"hello\" in foo\r\n In an equation for `bar': bar = let ?x = \"hello\" in foo\r\n}}}\r\n\r\nObviously, it should only print this error once. I encountered this in a larger program where it meant I got ''eight'' identical type errors at the same source position!","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5248Infer type context in a type signature2019-07-07T18:56:12ZgidynInfer type context in a type signatureIf I have code such as
```
class Foo f where
foo :: a -> f a
data Bar f a = Foo f => Bar {bar :: f a}
instance Foo (Bar f) where
foo a = Bar (foo a)
```
GHC will demand `Foo f =>` on the instance declaration, even though this...If I have code such as
```
class Foo f where
foo :: a -> f a
data Bar f a = Foo f => Bar {bar :: f a}
instance Foo (Bar f) where
foo a = Bar (foo a)
```
GHC will demand `Foo f =>` on the instance declaration, even though this can be inferred from the definition of Bar.
I understand *why* this is happening, but it should not be necessary to repeat information already given. Some code violates DRY dozens of times because of this limitation.7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/5296Add explicit type applications2019-07-07T18:56:00ZdsfAdd explicit type applicationsThis example is derived from code in my application. It works, but I can't add a signature to it. In other places it is preventing some code from compiling at all.
```
{-# LANGUAGE KindSignatures, MultiParamTypeClasses, RankNTypes #-}
{...This example is derived from code in my application. It works, but I can't add a signature to it. In other places it is preventing some code from compiling at all.
```
{-# LANGUAGE KindSignatures, MultiParamTypeClasses, RankNTypes #-}
{-# OPTIONS -Wall #-}
module Test where
class C t1 t2 m where method :: Int -> m t2
f :: forall t1 t2 (m :: * -> *). C t1 t2 m => Int -> m t2
f x = method x
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"Compile succeeds without signature, but fails with the signature suggested by GHC","status":"New","operating_system":"Linux","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"This example is derived from code in my application. It works, but I can't add a signature to it. In other places it is preventing some code from compiling at all.\r\n\r\n{{{\r\n{-# LANGUAGE KindSignatures, MultiParamTypeClasses, RankNTypes #-}\r\n{-# OPTIONS -Wall #-}\r\nmodule Test where\r\n\r\nclass C t1 t2 m where method :: Int -> m t2\r\n\r\nf :: forall t1 t2 (m :: * -> *). C t1 t2 m => Int -> m t2\r\nf x = method x\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/5321Very slow constraint solving for type families2019-07-07T18:55:54ZSimon Peyton JonesVery slow constraint solving for type familiesThis post (to the ghc-users mailing list, from Gershom Bazerman) is in literate Haskell. It describes how certain performance leaks are introduced in type level programming. These leaks do not affect program runtimes, but can cause compi...This post (to the ghc-users mailing list, from Gershom Bazerman) is in literate Haskell. It describes how certain performance leaks are introduced in type level programming. These leaks do not affect program runtimes, but can cause compile times to grow drastically. They exist both with Functional Dependencies and Type Families, but are currently worse with the former, and have grown worse with the new constraint solver in GHC 7. It is intended both as a guide to those encountering these issues, and as a motivation for the GHC development team to address such issues as the constraint solver is developed and improved.
```
> {-# OPTIONS_GHC -fcontext-stack=1000 #-} {-# LANGUAGE
> FlexibleContexts, FlexibleInstances, FunctionalDependencies,
> MultiParamTypeClasses, OverlappingInstances, TypeSynonymInstances,
> TypeOperators, UndecidableInstances, TypeFamilies #-} module
> TypePerformance where
```
Our running example, for simplicity's sake, is a type-level map of a single function. For reference, here is the code for a simple value-level map of a single function.
```
> vfoo = id
> mapfoo (x : xs) = vfoo x : mapfoo xs
> mapfoo [] = []
```
Because Haskell is a lazy language, this runs in O(n) time and constant stack.
We now lift map to the type level, to operate over HLists.
First, the basic HList types
```
> infixr 3 :*
> data x :* xs = x :* xs deriving Show
> data HNil = HNil deriving Show
```
Next, a large boring HList
```
> -- Adds ten cells
> addData x = i :* i :* d :* d :* s :*
> i :* i :* d :* d :* s :*
> x
> where i = 1 :: Int
> d = 1 :: Double
> s = ""
>
> -- Has 70 cells.
> sampleData = addData $ addData $ addData $ addData $ addData $
> addData $ addData $
> HNil
```
Next, a simple polymorphic function to map
```
> class Foo x y | x -> y
> where foo :: x -> y
> foo = undefined
> instance Foo Int Double
> instance Foo Double Int
> instance Foo String String
```
Now, our map
```
> class HMapFoo1 as bs | as -> bs where
> hMapFoo1 :: as -> bs
>
> instance (Foo a b, HMapFoo1 as bs) => HMapFoo1 (a :* as) (b :* bs) where
> hMapFoo1 (x :* xs) = foo x :* hMapFoo1 xs
>
> instance HMapFoo1 HNil HNil where
> hMapFoo1 _ = HNil
```
If we enable the following line, compilation time is \~ 9 seconds.
```
> testHMapFoo1 = hMapFoo1 sampleData
```
Furthermore, playing with the size of sampleData, we see that the time spent in compilation is superlinear -- each additional cell costs a greater amount of time. This is because while Haskell is lazy at the value level, it is strict at the type level. Therefore, just as in a strict language, HMapFoo1's cost grows O(n\*\*2) because even as we induct over the as, we build up a stack of bs. Just as in a strict language, the solution is to make hMapFoo tail recursive through introducing an accumulator. This also reverses the hlist, but never mind that.
```
> class HMapFoo2 acc as bs | acc as -> bs where
> hMapFoo2 :: acc -> as -> bs
>
> instance (Foo a b, HMapFoo2 (b :* bs) as res) => HMapFoo2 bs (a :* as) res where
> hMapFoo2 acc (x :* xs) = hMapFoo2 (foo x :* acc) xs
>
> instance HMapFoo2 acc HNil acc where
> hMapFoo2 acc _ = acc
```
If we enable the following line, compilation time is a much more satisfying \~0.5s.
```
> testHMapFoo2 = hMapFoo2 HNil sampleData
```
But wait, there's trouble on the horizon! Consider the following version:
```
> class HMapFoo3 acc as bs | acc as -> bs where
> hMapFoo3 :: acc -> as -> bs
>
> instance (HMapFoo3 (b :* bs) as res, Foo a b) => HMapFoo3 bs (a :* as) res where
> hMapFoo3 acc (x :* xs) = hMapFoo3 (foo x :* acc) xs
>
> instance HMapFoo3 acc HNil acc where
> hMapFoo3 acc _ = acc
```
The only difference between hMapFoo2 and hMapFoo3 is that the order of constraints on the inductive case has been reversed, with the recursive constraint first and the immediately checkable constraint second. Now, if we enable the following line, compilation time rockets to \~6s!
```
> testHMapFoo3 = hMapFoo3 HNil sampleData
```
Slowdowns such as those described here are not a purely hypothetical issue, but have caused real problems in production code. The example given above is fairly simple. The constraints used are minimal and easily checked. In real programs, the constraints are more difficult, increasing constant factors significantly. These constant factors, combined with unexpected algorithmic slowdowns due to the type inference engine, can lead (and have lead) to compilation times of HList-style code becoming deeply unwieldy-to-unusable, and can lead (and have lead) to this occuring only well after this code has been introduced and used on smaller cases without trouble.
The constraint solver should certainly be smart enough to reduce the compile times of HMapFoo3 to those of HMapFoo2. In fact, with type families, the there is no difference (see below). Could the compiler be smart enough to do the same for HMapFoo1? I'm not sure. Certainly, it could at least knock down its own constant factors a bit, even if it can't improve the big-O performance there.
----
== Appendix: Examples with Type Families ==
As the below code demonstrates, the same issues demonstrated with Functional Dependencies also appear with Type Families, although less horribly, as their code-path seems more optimized in the current constraint solver:
```
> class TFoo x where
> type TFooFun x
> tfoo :: x -> TFooFun x
> tfoo = undefined
>
> instance TFoo Int where
> type TFooFun Int = Double
> instance TFoo Double where
> type TFooFun Double = Int
> instance TFoo String where
> type TFooFun String = String
>
> class THMapFoo1 as where
> type THMapFoo1Res as
> thMapFoo1 :: as -> THMapFoo1Res as
>
> instance (TFoo a, THMapFoo1 as) => THMapFoo1 (a :* as) where
> type THMapFoo1Res (a :* as) = TFooFun a :* THMapFoo1Res as
> thMapFoo1 (x :* xs) = tfoo x :* thMapFoo1 xs
>
> instance THMapFoo1 HNil where
> type THMapFoo1Res HNil = HNil
> thMapFoo1 _ = HNil
```
The following, when enabled, takes \~3.5s. This demonstrates that slowdown occurs with type families as well.
```
> testTHMapFoo1 = thMapFoo1 sampleData
> class THMapFoo2 acc as where
> type THMapFoo2Res acc as
> thMapFoo2 :: acc -> as -> THMapFoo2Res acc as
>
> instance (TFoo a, THMapFoo2 (TFooFun a :* acc) as) => THMapFoo2 acc (a :* as) where
> type THMapFoo2Res acc (a :* as) = THMapFoo2Res (TFooFun a :* acc) as
> thMapFoo2 acc (x :* xs) = thMapFoo2 (tfoo x :* acc) xs
>
> instance THMapFoo2 acc HNil where
> type THMapFoo2Res acc HNil = acc
> thMapFoo2 acc _ = acc
```
The following, when enabled, takes \~0.6s. This demonstrates that the tail recursive transform fixes the slowdown with type families just as with fundeps.
```
> testTHMapFoo2 = thMapFoo2 HNil sampleData
> class THMapFoo3 acc as where
> type THMapFoo3Res acc as
> thMapFoo3 :: acc -> as -> THMapFoo3Res acc as
>
> instance (THMapFoo3 (TFooFun a :* acc) as, TFoo a) => THMapFoo3 acc (a :* as) where
> type THMapFoo3Res acc (a :* as) = THMapFoo3Res (TFooFun a :* acc) as
> thMapFoo3 acc (x :* xs) = thMapFoo3 (tfoo x :* acc) xs
>
> instance THMapFoo3 acc HNil where
> type THMapFoo3Res acc HNil = acc
> thMapFoo3 acc _ = acc
```
The following, when enabled, also takes \~0.6s. This demonstrates that, unlike the fundep case, the order of type class constraints does not, in this instance, affect the performance of type families.
```
> testTHMapFoo3 = thMapFoo3 HNil sampleData
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------------ |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | dimitris@microsoft.com, gershomb@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Very slow constraint solving for type families","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["dimitris@microsoft.com","gershomb@gmail.com"],"type":"Bug","description":"This post (to the ghc-users mailing list, from Gershom Bazerman) is in literate Haskell. It describes how certain performance leaks are introduced in type level programming. These leaks do not affect program runtimes, but can cause compile times to grow drastically. They exist both with Functional Dependencies and Type Families, but are currently worse with the former, and have grown worse with the new constraint solver in GHC 7. It is intended both as a guide to those encountering these issues, and as a motivation for the GHC development team to address such issues as the constraint solver is developed and improved. \r\n\r\n{{{\r\n> {-# OPTIONS_GHC -fcontext-stack=1000 #-} {-# LANGUAGE \r\n> FlexibleContexts, FlexibleInstances, FunctionalDependencies, \r\n> MultiParamTypeClasses, OverlappingInstances, TypeSynonymInstances, \r\n> TypeOperators, UndecidableInstances, TypeFamilies #-} module \r\n> TypePerformance where\r\n}}}\r\nOur running example, for simplicity's sake, is a type-level map of a single function. For reference, here is the code for a simple value-level map of a single function. \r\n{{{\r\n> vfoo = id\r\n> mapfoo (x : xs) = vfoo x : mapfoo xs\r\n> mapfoo [] = []\r\n}}}\r\nBecause Haskell is a lazy language, this runs in O(n) time and constant stack. \r\n\r\nWe now lift map to the type level, to operate over HLists. \r\n\r\nFirst, the basic HList types \r\n{{{\r\n> infixr 3 :*\r\n> data x :* xs = x :* xs deriving Show\r\n> data HNil = HNil deriving Show\r\n}}}\r\nNext, a large boring HList \r\n{{{\r\n> -- Adds ten cells\r\n> addData x = i :* i :* d :* d :* s :* \r\n> i :* i :* d :* d :* s :* \r\n> x \r\n> where i = 1 :: Int \r\n> d = 1 :: Double \r\n> s = \"\" \r\n> \r\n> -- Has 70 cells. \r\n> sampleData = addData $ addData $ addData $ addData $ addData $ \r\n> addData $ addData $ \r\n> HNil\r\n}}}\r\nNext, a simple polymorphic function to map \r\n{{{\r\n> class Foo x y | x -> y \r\n> where foo :: x -> y \r\n> foo = undefined\r\n\r\n> instance Foo Int Double\r\n> instance Foo Double Int\r\n> instance Foo String String\r\n}}}\r\nNow, our map \r\n{{{\r\n> class HMapFoo1 as bs | as -> bs where \r\n> hMapFoo1 :: as -> bs\r\n> \r\n> instance (Foo a b, HMapFoo1 as bs) => HMapFoo1 (a :* as) (b :* bs) where \r\n> hMapFoo1 (x :* xs) = foo x :* hMapFoo1 xs\r\n> \r\n> instance HMapFoo1 HNil HNil where \r\n> hMapFoo1 _ = HNil\r\n}}}\r\nIf we enable the following line, compilation time is ~ 9 seconds. \r\n{{{\r\n > testHMapFoo1 = hMapFoo1 sampleData \r\n}}}\r\nFurthermore, playing with the size of sampleData, we see that the time spent in compilation is superlinear -- each additional cell costs a greater amount of time. This is because while Haskell is lazy at the value level, it is strict at the type level. Therefore, just as in a strict language, HMapFoo1's cost grows O(n**2) because even as we induct over the as, we build up a stack of bs. Just as in a strict language, the solution is to make hMapFoo tail recursive through introducing an accumulator. This also reverses the hlist, but never mind that. \r\n{{{\r\n> class HMapFoo2 acc as bs | acc as -> bs where \r\n> hMapFoo2 :: acc -> as -> bs\r\n> \r\n> instance (Foo a b, HMapFoo2 (b :* bs) as res) => HMapFoo2 bs (a :* as) res where \r\n> hMapFoo2 acc (x :* xs) = hMapFoo2 (foo x :* acc) xs\r\n> \r\n> instance HMapFoo2 acc HNil acc where \r\n> hMapFoo2 acc _ = acc\r\n}}}\r\nIf we enable the following line, compilation time is a much more satisfying ~0.5s. \r\n{{{\r\n > testHMapFoo2 = hMapFoo2 HNil sampleData \r\n}}}\r\nBut wait, there's trouble on the horizon! Consider the following version: \r\n{{{\r\n> class HMapFoo3 acc as bs | acc as -> bs where \r\n> hMapFoo3 :: acc -> as -> bs\r\n> \r\n> instance (HMapFoo3 (b :* bs) as res, Foo a b) => HMapFoo3 bs (a :* as) res where \r\n> hMapFoo3 acc (x :* xs) = hMapFoo3 (foo x :* acc) xs\r\n> \r\n> instance HMapFoo3 acc HNil acc where \r\n> hMapFoo3 acc _ = acc\r\n}}}\r\nThe only difference between hMapFoo2 and hMapFoo3 is that the order of constraints on the inductive case has been reversed, with the recursive constraint first and the immediately checkable constraint second. Now, if we enable the following line, compilation time rockets to ~6s! \r\n{{{\r\n > testHMapFoo3 = hMapFoo3 HNil sampleData \r\n}}}\r\nSlowdowns such as those described here are not a purely hypothetical issue, but have caused real problems in production code. The example given above is fairly simple. The constraints used are minimal and easily checked. In real programs, the constraints are more difficult, increasing constant factors significantly. These constant factors, combined with unexpected algorithmic slowdowns due to the type inference engine, can lead (and have lead) to compilation times of HList-style code becoming deeply unwieldy-to-unusable, and can lead (and have lead) to this occuring only well after this code has been introduced and used on smaller cases without trouble. \r\n\r\nThe constraint solver should certainly be smart enough to reduce the compile times of HMapFoo3 to those of HMapFoo2. In fact, with type families, the there is no difference (see below). Could the compiler be smart enough to do the same for HMapFoo1? I'm not sure. Certainly, it could at least knock down its own constant factors a bit, even if it can't improve the big-O performance there. \r\n\r\n----\r\n== Appendix: Examples with Type Families ==\r\n\r\nAs the below code demonstrates, the same issues demonstrated with Functional Dependencies also appear with Type Families, although less horribly, as their code-path seems more optimized in the current constraint solver: \r\n{{{\r\n> class TFoo x where \r\n> type TFooFun x \r\n> tfoo :: x -> TFooFun x \r\n> tfoo = undefined\r\n> \r\n> instance TFoo Int where \r\n> type TFooFun Int = Double\r\n> instance TFoo Double where \r\n> type TFooFun Double = Int\r\n> instance TFoo String where \r\n> type TFooFun String = String\r\n> \r\n> class THMapFoo1 as where \r\n> type THMapFoo1Res as \r\n> thMapFoo1 :: as -> THMapFoo1Res as\r\n> \r\n> instance (TFoo a, THMapFoo1 as) => THMapFoo1 (a :* as) where \r\n> type THMapFoo1Res (a :* as) = TFooFun a :* THMapFoo1Res as \r\n> thMapFoo1 (x :* xs) = tfoo x :* thMapFoo1 xs\r\n> \r\n> instance THMapFoo1 HNil where \r\n> type THMapFoo1Res HNil = HNil \r\n> thMapFoo1 _ = HNil\r\n}}}\r\nThe following, when enabled, takes ~3.5s. This demonstrates that slowdown occurs with type families as well. \r\n{{{\r\n > testTHMapFoo1 = thMapFoo1 sampleData \r\n\r\n> class THMapFoo2 acc as where \r\n> type THMapFoo2Res acc as \r\n> thMapFoo2 :: acc -> as -> THMapFoo2Res acc as\r\n> \r\n> instance (TFoo a, THMapFoo2 (TFooFun a :* acc) as) => THMapFoo2 acc (a :* as) where \r\n> type THMapFoo2Res acc (a :* as) = THMapFoo2Res (TFooFun a :* acc) as \r\n> thMapFoo2 acc (x :* xs) = thMapFoo2 (tfoo x :* acc) xs\r\n> \r\n> instance THMapFoo2 acc HNil where \r\n> type THMapFoo2Res acc HNil = acc \r\n> thMapFoo2 acc _ = acc\r\n}}}\r\nThe following, when enabled, takes ~0.6s. This demonstrates that the tail recursive transform fixes the slowdown with type families just as with fundeps. \r\n{{{\r\n > testTHMapFoo2 = thMapFoo2 HNil sampleData \r\n\r\n> class THMapFoo3 acc as where \r\n> type THMapFoo3Res acc as \r\n> thMapFoo3 :: acc -> as -> THMapFoo3Res acc as\r\n> \r\n> instance (THMapFoo3 (TFooFun a :* acc) as, TFoo a) => THMapFoo3 acc (a :* as) where \r\n> type THMapFoo3Res acc (a :* as) = THMapFoo3Res (TFooFun a :* acc) as \r\n> thMapFoo3 acc (x :* xs) = thMapFoo3 (tfoo x :* acc) xs\r\n> \r\n> instance THMapFoo3 acc HNil where \r\n> type THMapFoo3Res acc HNil = acc \r\n> thMapFoo3 acc _ = acc\r\n}}}\r\nThe following, when enabled, also takes ~0.6s. This demonstrates that, unlike the fundep case, the order of type class constraints does not, in this instance, affect the performance of type families. \r\n{{{\r\n > testTHMapFoo3 = thMapFoo3 HNil sampleData \r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/5333Arrow command combinators and infixr cause the desugarer to fail2019-07-07T18:55:51ZpetegArrow command combinators and infixr cause the desugarer to failThe following code exhibits the bug:
```
{-# LANGUAGE Arrows, NoMonomorphismRestriction #-}
module T where
import Prelude hiding ( id, (.) )
import Control.Arrow
cc1 :: Arrow a => a e b -> a e b -> a e b
cc1 = undefined
-- 'g' fails ...The following code exhibits the bug:
```
{-# LANGUAGE Arrows, NoMonomorphismRestriction #-}
module T where
import Prelude hiding ( id, (.) )
import Control.Arrow
cc1 :: Arrow a => a e b -> a e b -> a e b
cc1 = undefined
-- 'g' fails to compile.
-- g = proc (x, y, z) ->
-- ((returnA -< x) &&& (returnA -< y) &&& (returnA -< z))
-- 'f' compiles:
-- - without an infix declaration
-- - with the infixl declaration
-- and fails with the infixr declaration
infixr 6 `cc1`
-- infixl 6 `cc1`
f = proc (x, y, z) ->
((returnA -< x) `cc1` (returnA -< y) `cc1` (returnA -< z))
```
GHC says:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.0.3 for i386-apple-darwin):
dsSyntaxTable Not found: base:GHC.Desugar.>>>{v 01W}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | peteg42@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Arrow command combinators and infixr cause the desugarer to fail","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["peteg42@gmail.com"],"type":"Bug","description":"The following code exhibits the bug:\r\n\r\n{{{\r\n{-# LANGUAGE Arrows, NoMonomorphismRestriction #-}\r\nmodule T where\r\n\r\nimport Prelude hiding ( id, (.) )\r\nimport Control.Arrow\r\n\r\ncc1 :: Arrow a => a e b -> a e b -> a e b\r\ncc1 = undefined\r\n\r\n-- 'g' fails to compile.\r\n-- g = proc (x, y, z) ->\r\n-- ((returnA -< x) &&& (returnA -< y) &&& (returnA -< z))\r\n\r\n-- 'f' compiles:\r\n-- - without an infix declaration\r\n-- - with the infixl declaration\r\n-- and fails with the infixr declaration\r\ninfixr 6 `cc1`\r\n-- infixl 6 `cc1`\r\n\r\nf = proc (x, y, z) ->\r\n ((returnA -< x) `cc1` (returnA -< y) `cc1` (returnA -< z))\r\n\r\n}}}\r\n\r\nGHC says:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.0.3 for i386-apple-darwin):\r\n\tdsSyntaxTable Not found: base:GHC.Desugar.>>>{v 01W}\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Ross Patersonr.paterson@city.ac.ukRoss Patersonr.paterson@city.ac.ukhttps://gitlab.haskell.org/ghc/ghc/-/issues/5483Eta-reduced term has wrongly inferred monomorphic type2019-07-07T18:55:05ZdarchonEta-reduced term has wrongly inferred monomorphic typeHi,
When creating a file with the following two definitions:
```
rowtotals xs = map sum xs
rowtotals' = map sum
```
And loading this file in GHCi. Asking for the type of the two definitions gives:
```
*Main> :t rowtotals
rowtotals ...Hi,
When creating a file with the following two definitions:
```
rowtotals xs = map sum xs
rowtotals' = map sum
```
And loading this file in GHCi. Asking for the type of the two definitions gives:
```
*Main> :t rowtotals
rowtotals :: Num b => [[b]] -> [b]
*Main> :t rowtotals'
rowtotals' :: [[Integer]] -> [Integer]
```
Is this the expected behaviour? I would expect both to have the same polymorphic type.
Cheers, Christiaan
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.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":"Eta-reduced term has wrongly inferred monomorphic type","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hi,\r\n\r\nWhen creating a file with the following two definitions:\r\n\r\n{{{\r\nrowtotals xs = map sum xs\r\nrowtotals' = map sum\r\n}}}\r\n\r\nAnd loading this file in GHCi. Asking for the type of the two definitions gives:\r\n\r\n{{{\r\n*Main> :t rowtotals\r\nrowtotals :: Num b => [[b]] -> [b]\r\n*Main> :t rowtotals'\r\nrowtotals' :: [[Integer]] -> [Integer]\r\n}}}\r\n\r\nIs this the expected behaviour? I would expect both to have the same polymorphic type.\r\n\r\nCheers, Christiaan","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5577Two arguments are not two arguments according to the type checker2019-07-07T18:54:40ZjosefTwo arguments are not two arguments according to the type checkerI got a very strange type error message from GHC today. I've inserted it at the end of this message. It is misleading because it complains that a "lambda expression \[...\] has two arguments, but its type \[...\] has only two". Now, I kn...I got a very strange type error message from GHC today. I've inserted it at the end of this message. It is misleading because it complains that a "lambda expression \[...\] has two arguments, but its type \[...\] has only two". Now, I know that the code contains type errors but the error message could be more helpful.
The code fragment which provokes this message looks as follows:
```
let writeElement = case ty of
Core.FloatType ->
\ix element -> tell [loc :!: ix := LitF element]
```
The `Core.FloatType` constructor is part of a GADT, the case ought to refine the type of `element` to `Float`. I don't know if that's what's tripping GHC up. The actual error has to do with the type of `ix` which should be of type `Expr` but the function `writeElement` is applied to an argument of type `Integer`.
The error message:
```
Couldn't match type `Expr' with `Integer'
The lambda expression `\ ix element -> tell ...' has two arguments,
but its type `Integer
-> b0
-> RWST () [Prog] Integer Data.Functor.Identity.Identity c0'
has only two
In the expression:
\ ix element -> tell [loc :!: ix := LitF element]
In a case alternative:
Core.FloatType -> \ ix element -> tell [loc :!: ix := LitF element]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.3 |
| 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":"Two arguments are not two arguments according to the type checker","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I got a very strange type error message from GHC today. I've inserted it at the end of this message. It is misleading because it complains that a \"lambda expression [...] has two arguments, but its type [...] has only two\". Now, I know that the code contains type errors but the error message could be more helpful.\r\n\r\nThe code fragment which provokes this message looks as follows:\r\n{{{\r\nlet writeElement = case ty of\r\n Core.FloatType ->\r\n \\ix element -> tell [loc :!: ix := LitF element]\r\n}}}\r\nThe `Core.FloatType` constructor is part of a GADT, the case ought to refine the type of `element` to `Float`. I don't know if that's what's tripping GHC up. The actual error has to do with the type of `ix` which should be of type `Expr` but the function `writeElement` is applied to an argument of type `Integer`.\r\n\r\nThe error message:\r\n{{{\r\n Couldn't match type `Expr' with `Integer'\r\n The lambda expression `\\ ix element -> tell ...' has two arguments,\r\n but its type `Integer\r\n -> b0\r\n -> RWST () [Prog] Integer Data.Functor.Identity.Identity c0'\r\n has only two\r\n In the expression:\r\n \\ ix element -> tell [loc :!: ix := LitF element]\r\n In a case alternative:\r\n Core.FloatType -> \\ ix element -> tell [loc :!: ix := LitF element]\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5581ConstraintKinds lets you put the typechecker into a loop2019-07-07T18:54:39ZpumpkinConstraintKinds lets you put the typechecker into a loopEd Kmett was playing with them the other day and Dan Doel and I reduced the issue to this:
```
{-# LANGUAGE ConstraintKinds, FlexibleContexts, FlexibleInstances, KindSignatures #-}
class C (p :: Constraint)
class D (p :: Constraint)
i...Ed Kmett was playing with them the other day and Dan Doel and I reduced the issue to this:
```
{-# LANGUAGE ConstraintKinds, FlexibleContexts, FlexibleInstances, KindSignatures #-}
class C (p :: Constraint)
class D (p :: Constraint)
instance C (D p) => C (D (D p))
{-
-- This works
data E a = E
class F a
instance F (E a) => F (E (E a))
-}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.3 |
| 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":"ConstraintKinds lets you put the typechecker into a loop","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.3","keywords":["ConstraintKinds"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Ed Kmett was playing with them the other day and Dan Doel and I reduced the issue to this:\r\n\r\n{{{\r\n{-# LANGUAGE ConstraintKinds, FlexibleContexts, FlexibleInstances, KindSignatures #-}\r\n\r\nclass C (p :: Constraint)\r\nclass D (p :: Constraint)\r\n\r\ninstance C (D p) => C (D (D p))\r\n\r\n{-\r\n-- This works\r\ndata E a = E\r\nclass F a\r\ninstance F (E a) => F (E (E a))\r\n-}\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->batterseapowerbatterseapowerhttps://gitlab.haskell.org/ghc/ghc/-/issues/5591Type constructor variables not injective2019-07-07T18:54:36Zdaniel.is.fischerType constructor variables not injectiveI'm not sure whether it is a bug, but there have been two recent reports of ghc-7.2.1 not treating type constructor variables as injective. First, by [Daniel Schüssler](http://haskell.org/pipermail/haskell-cafe/2011-October/096221.html),...I'm not sure whether it is a bug, but there have been two recent reports of ghc-7.2.1 not treating type constructor variables as injective. First, by [Daniel Schüssler](http://haskell.org/pipermail/haskell-cafe/2011-October/096221.html),
```
{-# LANGUAGE GADTs, TypeOperators, TypeFamilies, ScopedTypeVariables #-}
module DTest where
data a :=: b where
Refl :: a :=: a
subst :: a :=: b -> f a -> f b
subst Refl = id
-- Then this doesn't work (error message at the bottom):
inj1 :: forall f a b. f a :=: f b -> a :=: b
inj1 Refl = Refl
-- But one can still construct it with a trick that Oleg used in the context of
-- Leibniz equality:
type family Arg fa
type instance Arg (f a) = a
newtype Helper fa fa' = Helper { runHelper :: Arg fa :=: Arg fa' }
inj2 :: forall f a b. f a :=: f b -> a :=: b
inj2 p = runHelper (subst p (Helper Refl :: Helper (f a) (f a)))
{-
DTest.hs:13:13:
Could not deduce (a ~ b)
from the context (f a ~ f b)
bound by a pattern with constructor
Refl :: forall a. a :=: a,
in an equation for `inj1'
at DTest.hs:13:6-9
`a' is a rigid type variable bound by
the type signature for inj1 :: (f a :=: f b) -> a :=: b
at DTest.hs:13:1
`b' is a rigid type variable bound by
the type signature for inj1 :: (f a :=: f b) -> a :=: b
at DTest.hs:13:1
Expected type: a :=: b
Actual type: a :=: a
In the expression: Refl
In an equation for `inj1': inj1 Refl = Refl
-}
```
compiles fine with ghc-7.0.4. Second, by [Sjoerd Visscher](http://stackoverflow.com/questions/7866375/why-does-ghc-think-that-this-type-variable-is-not-injective),
```
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, KindSignatures,
GADTs, FlexibleInstances, FlexibleContexts #-}
module STest where
class Monad m => Effect p e r m | p e m -> r where
fin :: p e m -> e -> m r
data ErrorEff :: * -> (* -> *) -> * where
CatchError :: (e -> m a) -> ErrorEff ((e -> m a) -> m a) m
instance Monad m => Effect ErrorEff ((e -> m a) -> m a) a m where
fin (CatchError h) = \f -> f h
{-
STest.hs:12:32:
Could not deduce (a1 ~ a)
from the context (Monad m)
bound by the instance declaration at STest.hs:11:10-59
or from (((e -> m a) -> m a) ~ ((e1 -> m a1) -> m a1))
bound by a pattern with constructor
CatchError :: forall (m :: * -> *) e a.
(e -> m a) -> ErrorEff ((e -> m a) -> m a) m,
in an equation for `fin'
at STest.hs:12:8-19
`a1' is a rigid type variable bound by
a pattern with constructor
CatchError :: forall (m :: * -> *) e a.
(e -> m a) -> ErrorEff ((e -> m a) -> m a) m,
in an equation for `fin'
at STest.hs:12:8
`a' is a rigid type variable bound by
the instance declaration at STest.hs:11:46
Expected type: e1 -> m a1
Actual type: e -> m a
In the first argument of `f', namely `h'
In the expression: f h
-}
```
also compiles fine with 7.0.4. ghc-7.3.20111026 behaves like 7.2.1. Which version behaves correctly?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.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":"Type constructor variables not injective","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm not sure whether it is a bug, but there have been two recent reports of ghc-7.2.1 not treating type constructor variables as injective. First, by [http://haskell.org/pipermail/haskell-cafe/2011-October/096221.html Daniel Schüssler],\r\n{{{\r\n{-# LANGUAGE GADTs, TypeOperators, TypeFamilies, ScopedTypeVariables #-}\r\nmodule DTest where\r\n\r\ndata a :=: b where \r\n Refl :: a :=: a\r\n\r\nsubst :: a :=: b -> f a -> f b\r\nsubst Refl = id \r\n\r\n-- Then this doesn't work (error message at the bottom):\r\n\r\ninj1 :: forall f a b. f a :=: f b -> a :=: b\r\ninj1 Refl = Refl\r\n\r\n-- But one can still construct it with a trick that Oleg used in the context of \r\n-- Leibniz equality:\r\n\r\ntype family Arg fa\r\n\r\ntype instance Arg (f a) = a\r\n\r\nnewtype Helper fa fa' = Helper { runHelper :: Arg fa :=: Arg fa' }\r\n\r\ninj2 :: forall f a b. f a :=: f b -> a :=: b\r\ninj2 p = runHelper (subst p (Helper Refl :: Helper (f a) (f a)))\r\n\r\n{-\r\nDTest.hs:13:13:\r\n Could not deduce (a ~ b)\r\n from the context (f a ~ f b)\r\n bound by a pattern with constructor\r\n Refl :: forall a. a :=: a,\r\n in an equation for `inj1'\r\n at DTest.hs:13:6-9\r\n `a' is a rigid type variable bound by\r\n the type signature for inj1 :: (f a :=: f b) -> a :=: b\r\n at DTest.hs:13:1\r\n `b' is a rigid type variable bound by\r\n the type signature for inj1 :: (f a :=: f b) -> a :=: b\r\n at DTest.hs:13:1\r\n Expected type: a :=: b\r\n Actual type: a :=: a\r\n In the expression: Refl\r\n In an equation for `inj1': inj1 Refl = Refl\r\n-}\r\n}}}\r\ncompiles fine with ghc-7.0.4. Second, by [http://stackoverflow.com/questions/7866375/why-does-ghc-think-that-this-type-variable-is-not-injective Sjoerd Visscher],\r\n{{{\r\n{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, KindSignatures, \r\n GADTs, FlexibleInstances, FlexibleContexts #-}\r\nmodule STest where\r\n\r\nclass Monad m => Effect p e r m | p e m -> r where\r\n fin :: p e m -> e -> m r\r\n\r\ndata ErrorEff :: * -> (* -> *) -> * where \r\n CatchError :: (e -> m a) -> ErrorEff ((e -> m a) -> m a) m\r\n\r\ninstance Monad m => Effect ErrorEff ((e -> m a) -> m a) a m where\r\n fin (CatchError h) = \\f -> f h\r\n\r\n{-\r\nSTest.hs:12:32:\r\n Could not deduce (a1 ~ a)\r\n from the context (Monad m)\r\n bound by the instance declaration at STest.hs:11:10-59\r\n or from (((e -> m a) -> m a) ~ ((e1 -> m a1) -> m a1))\r\n bound by a pattern with constructor\r\n CatchError :: forall (m :: * -> *) e a.\r\n (e -> m a) -> ErrorEff ((e -> m a) -> m a) m,\r\n in an equation for `fin'\r\n at STest.hs:12:8-19\r\n `a1' is a rigid type variable bound by\r\n a pattern with constructor\r\n CatchError :: forall (m :: * -> *) e a.\r\n (e -> m a) -> ErrorEff ((e -> m a) -> m a) m,\r\n in an equation for `fin'\r\n at STest.hs:12:8\r\n `a' is a rigid type variable bound by\r\n the instance declaration at STest.hs:11:46\r\n Expected type: e1 -> m a1\r\n Actual type: e -> m a\r\n In the first argument of `f', namely `h'\r\n In the expression: f h\r\n-}\r\n}}}\r\nalso compiles fine with 7.0.4. ghc-7.3.20111026 behaves like 7.2.1. Which version behaves correctly?","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/5596"f c = a $ b c", "f = a . b" does not.2019-07-07T18:54:34Zguest"f c = a $ b c", "f = a . b" does not.the following code produces a type error, and i think it shouldn't:
```
{-# LANGUAGE ScopedTypeVariables, MultiParamTypeClasses #-}
module Main
where
import Control.Monad.ST
import Data.STRef
import Text.Parsec
type P v a = ParsecT T...the following code produces a type error, and i think it shouldn't:
```
{-# LANGUAGE ScopedTypeVariables, MultiParamTypeClasses #-}
module Main
where
import Control.Monad.ST
import Data.STRef
import Text.Parsec
type P v a = ParsecT TokStream () (ST v) a
data TokStream = TokStream [Char]
instance Stream TokStream (ST v) Char where
uncons (TokStream []) = return Nothing
uncons (TokStream (t:ts)) = return (Just (t, TokStream ts))
c :: P v ()
c = return ()
works :: [Char] -> Either ParseError ()
works toks = runST $ f $ TokStream toks
where
f :: forall v . TokStream -> ST v (Either ParseError ())
f = runPT c () "<sourcefile>"
doesnt :: [Char] -> Either ParseError ()
doesnt = runST . f . TokStream
where
f :: forall v . TokStream -> ST v (Either ParseError ())
f = runPT c () "<sourcefile>"
```
doesnt should be equivalent to works, but works works and doesnt doesn't. the type error:
```
Couldn't match expected type `forall s.
ST s (Either ParseError ())'
with actual type `ST v0 (Either ParseError ())'
Expected type: TokStream -> forall s. ST s (Either ParseError ())
Actual type: TokStream -> ST v0 (Either ParseError ())
In the first argument of `(.)', namely `f'
In the second argument of `(.)', namely `f . TokStream'
```
I tried this on 7.2.1 and 7.0.3. may be related to tickets 4347 or 4310, but I don't know enough about the ghc type engine to tell.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.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":"\"f c = a $ b c\", \"f = a . b\" does not.","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"the following code produces a type error, and i think it shouldn't:\r\n\r\n\r\n{{{\r\n{-# LANGUAGE ScopedTypeVariables, MultiParamTypeClasses #-}\r\nmodule Main\r\nwhere\r\n\r\nimport Control.Monad.ST\r\nimport Data.STRef\r\nimport Text.Parsec\r\n\r\n\r\ntype P v a = ParsecT TokStream () (ST v) a\r\n\r\ndata TokStream = TokStream [Char]\r\n\r\ninstance Stream TokStream (ST v) Char where\r\n uncons (TokStream []) = return Nothing\r\n uncons (TokStream (t:ts)) = return (Just (t, TokStream ts))\r\n\r\nc :: P v ()\r\nc = return ()\r\n\r\nworks :: [Char] -> Either ParseError ()\r\nworks toks = runST $ f $ TokStream toks\r\n where\r\n f :: forall v . TokStream -> ST v (Either ParseError ())\r\n f = runPT c () \"<sourcefile>\"\r\n\r\ndoesnt :: [Char] -> Either ParseError ()\r\ndoesnt = runST . f . TokStream\r\n where\r\n f :: forall v . TokStream -> ST v (Either ParseError ())\r\n f = runPT c () \"<sourcefile>\"\r\n}}}\r\n\r\ndoesnt should be equivalent to works, but works works and doesnt doesn't. the type error:\r\n\r\n\r\n{{{\r\n\r\n Couldn't match expected type `forall s.\r\n ST s (Either ParseError ())'\r\n with actual type `ST v0 (Either ParseError ())'\r\n Expected type: TokStream -> forall s. ST s (Either ParseError ())\r\n Actual type: TokStream -> ST v0 (Either ParseError ())\r\n In the first argument of `(.)', namely `f'\r\n In the second argument of `(.)', namely `f . TokStream'\r\n\r\n}}}\r\n\r\nI tried this on 7.2.1 and 7.0.3. may be related to tickets 4347 or 4310, but I don't know enough about the ghc type engine to tell.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5600Instantiation of a rank 2 type fails for type synonyms2019-07-07T18:54:32ZpabaInstantiation of a rank 2 type fails for type synonymsThe instantiation of a rank 2 type with a type containing type synonyms that rearrange or omit type variables fails.
For example, consider the following function:
```
mapR :: Functor f => (forall a. g a -> b) -> f (g a) -> f b
mapR f t...The instantiation of a rank 2 type with a type containing type synonyms that rearrange or omit type variables fails.
For example, consider the following function:
```
mapR :: Functor f => (forall a. g a -> b) -> f (g a) -> f b
mapR f t = fmap f t
```
Now we want to instantiate the type variable g in the above type:
```
data F a = F a
type G a = F a
mapG :: Functor f => (forall a. G a -> b) -> f (G a) -> f b
mapG f t = mapR f t
```
This works fine. But if we change the definition of the type synonym G to
```
type G a = F ()
```
we get the following error message:
```
/home/paba/code/bug.hs:11:17:
Could not deduce (a1 ~ ())
from the context (Functor f)
bound by the type signature for
mapG :: Functor f => (forall a1. G a1 -> b) -> f (G a) -> f b
at /home/paba/code/bug.hs:11:1-19
`a1' is a rigid type variable bound by
a type expected by the context: F a1 -> b
at /home/paba/code/bug.hs:11:12
Expected type: F a -> b
Actual type: G a0 -> b
In the first argument of `mapR', namely `f'
In the expression: mapR f t
```
This only happens for rank 2 types. If we change the type of mapR by removing the quantifier, the instantiation of the type of mapR succeeds.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.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":"Instantiation of a rank 2 type fails for type synonyms","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The instantiation of a rank 2 type with a type containing type synonyms that rearrange or omit type variables fails.\r\n\r\nFor example, consider the following function:\r\n{{{\r\nmapR :: Functor f => (forall a. g a -> b) -> f (g a) -> f b\r\nmapR f t = fmap f t\r\n}}}\r\n\r\nNow we want to instantiate the type variable g in the above type:\r\n{{{\r\ndata F a = F a\r\ntype G a = F a\r\n\r\nmapG :: Functor f => (forall a. G a -> b) -> f (G a) -> f b\r\nmapG f t = mapR f t\r\n}}}\r\n\r\nThis works fine. But if we change the definition of the type synonym G to\r\n{{{\r\ntype G a = F ()\r\n}}}\r\nwe get the following error message:\r\n{{{\r\n/home/paba/code/bug.hs:11:17:\r\n Could not deduce (a1 ~ ())\r\n from the context (Functor f)\r\n bound by the type signature for\r\n mapG :: Functor f => (forall a1. G a1 -> b) -> f (G a) -> f b\r\n at /home/paba/code/bug.hs:11:1-19\r\n `a1' is a rigid type variable bound by\r\n a type expected by the context: F a1 -> b\r\n at /home/paba/code/bug.hs:11:12\r\n Expected type: F a -> b\r\n Actual type: G a0 -> b\r\n In the first argument of `mapR', namely `f'\r\n In the expression: mapR f t\r\n}}}\r\n\r\nThis only happens for rank 2 types. If we change the type of mapR by removing the quantifier, the instantiation of the type of mapR succeeds.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5609Type checking arrow notation in the presence of deferred constraints2019-07-07T18:54:27ZdreixelType checking arrow notation in the presence of deferred constraintsIn `TcArrows`, the following code
```
tc_cmd w_tv (cmd, i, b, tup_ty, s)
= do { tup_ty' <- zonkTcType tup_ty
; let (corner_ty, arg_tys) = unscramble tup_ty'
-- Check that it has the right shape:
-- ((w,s1) .. sn)
-...In `TcArrows`, the following code
```
tc_cmd w_tv (cmd, i, b, tup_ty, s)
= do { tup_ty' <- zonkTcType tup_ty
; let (corner_ty, arg_tys) = unscramble tup_ty'
-- Check that it has the right shape:
-- ((w,s1) .. sn)
-- where the si do not mention w
; checkTc (corner_ty `eqType` mkTyVarTy w_tv &&
not (w_tv `elemVarSet` tyVarsOfTypes arg_tys))
(badFormFun i tup_ty')
; tcCmdTop (env { cmd_arr = b }) cmd arg_tys s }
```
is wrong. In particular, the check `elemVarSet w_tv (tyVarsOfTypes arg_tys)` does not make sense in the presence of deferred constraints.
There is no testcase for this at the moment, but in the ghc-kinds branch both T5283 and arrowform1 fail because of this. The temporary fix was:
```
; _bogus <- unifyType corner_ty (mkTyVarTy w_tv)
; checkTc (not (w_tv `elemVarSet` tyVarsOfTypes arg_tys))
(badFormFun i tup_ty')
```
This solves only T5283 and arrowform1; other problems might arise in the future, so this should be fixed properly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.3 |
| 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":"Type checking arrow notation in the presence of deferred constraints","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In `TcArrows`, the following code\r\n\r\n{{{\r\n tc_cmd w_tv (cmd, i, b, tup_ty, s)\r\n = do { tup_ty' <- zonkTcType tup_ty\r\n\t ; let (corner_ty, arg_tys) = unscramble tup_ty'\r\n\r\n\t\t-- Check that it has the right shape:\r\n\t\t-- \t((w,s1) .. sn)\r\n\t\t-- where the si do not mention w\r\n\t ; checkTc (corner_ty `eqType` mkTyVarTy w_tv && \r\n\t\t not (w_tv `elemVarSet` tyVarsOfTypes arg_tys))\r\n\t\t (badFormFun i tup_ty')\r\n\r\n\t ; tcCmdTop (env { cmd_arr = b }) cmd arg_tys s }\r\n}}}\r\n\r\nis wrong. In particular, the check `elemVarSet w_tv (tyVarsOfTypes arg_tys)` does not make sense in the presence of deferred constraints.\r\n\r\nThere is no testcase for this at the moment, but in the ghc-kinds branch both T5283 and arrowform1 fail because of this. The temporary fix was:\r\n{{{\r\n ; _bogus <- unifyType corner_ty (mkTyVarTy w_tv)\r\n\t ; checkTc (not (w_tv `elemVarSet` tyVarsOfTypes arg_tys))\r\n\t\t (badFormFun i tup_ty')\r\n}}}\r\n\r\nThis solves only T5283 and arrowform1; other problems might arise in the future, so this should be fixed properly.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2Ross Patersonr.paterson@city.ac.ukRoss Patersonr.paterson@city.ac.ukhttps://gitlab.haskell.org/ghc/ghc/-/issues/5655Oddity with ConstraintKinds and TypeFamilies2019-07-07T18:54:10ZillissiusOddity with ConstraintKinds and TypeFamiliesSee the attached program (not sure how to reduce it further - I don't know whether the relevant interaction is really with !TypeFamilies, Rank2Types, or what).
When compiled with -DWORKAROUND, it compiles, when without, it doesn't. The ...See the attached program (not sure how to reduce it further - I don't know whether the relevant interaction is really with !TypeFamilies, Rank2Types, or what).
When compiled with -DWORKAROUND, it compiles, when without, it doesn't. The difference:
```
#ifndef WORKAROUND
ap :: (forall a. C e a => a -> r) -> e -> r
#else
ap :: c ~ C e => (forall a. c a => a -> r) -> e -> r
#endif
```
(Where 'C e' is an associated type of 'e' of kind \* -\> Constraint.)
I sort of assumed that 'Some Type' and 'a \~ Some Type =\> a' would always be equivalent, but maybe I'm wrong. Feel free to mark as invalid if I am.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.3 |
| 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":"Oddity with ConstraintKinds and TypeFamilies","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"See the attached program (not sure how to reduce it further - I don't know whether the relevant interaction is really with !TypeFamilies, Rank2Types, or what).\r\n\r\nWhen compiled with -DWORKAROUND, it compiles, when without, it doesn't. The difference:\r\n\r\n{{{\r\n#ifndef WORKAROUND\r\n ap :: (forall a. C e a => a -> r) -> e -> r\r\n#else\r\n ap :: c ~ C e => (forall a. c a => a -> r) -> e -> r\r\n#endif\r\n}}}\r\n\r\n(Where 'C e' is an associated type of 'e' of kind * -> Constraint.)\r\n\r\nI sort of assumed that 'Some Type' and 'a ~ Some Type => a' would always be equivalent, but maybe I'm wrong. Feel free to mark as invalid if I am.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5689The 'impossible' happened: type-inference succeeds somehow in code which isn'...2019-07-07T18:54:02ZnicolastThe 'impossible' happened: type-inference succeeds somehow in code which isn't type-safeWhile trying to figure out how Haskell handles OCaml's value restriction, I created some code which I thought shouldn't type-check.
It did, though, and makes GHCi panic on execution, or makes GHC fail during compilation.
Minor changes ...While trying to figure out how Haskell handles OCaml's value restriction, I created some code which I thought shouldn't type-check.
It did, though, and makes GHCi panic on execution, or makes GHC fail during compilation.
Minor changes to the code makes it no longer type-check, as expected.
Here's the code, including some comments which show when compilation does fail as expected:
```
{-# LANGUAGE ScopedTypeVariables #-}
import Data.IORef
main :: IO ()
main = do
(r :: IORef (t -> t)) <- newIORef id
-- r <- newIORef i -- => Type-check error
writeIORef r (\v -> if v then False else True)
c <- readIORef r
print $ c True
print $ c 1234
-- print $ c Nothing -- => Type-check error
-- print $ c (1 :: Int) -- => Type-check error
```
When replacing the "print $ c 1234" line with one of the last 2 lines, type-checking fails.
When removing the explicit type-annotation on 'r', type-checking fails when "print $ c 1234" is left in place.
Here's the GHCi and GHC output:
```
Prelude> :load demo1.hs
[1 of 1] Compiling Main ( demo1.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
ghc: panic! (the 'impossible' happened)
(GHC version 7.0.4 for x86_64-unknown-linux):
nameModule $dNum{v ann}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
```
$ ghc --make demo1.hs
[1 of 1] Compiling Main ( demo1.hs, demo1.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.0.4 for x86_64-unknown-linux):
initC: srt_lbl
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.4 |
| 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":"The 'impossible' happened: type-inference succeeds somehow in code which isn't type-safe","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While trying to figure out how Haskell handles OCaml's value restriction, I created some code which I thought shouldn't type-check.\r\n\r\nIt did, though, and makes GHCi panic on execution, or makes GHC fail during compilation.\r\n\r\nMinor changes to the code makes it no longer type-check, as expected.\r\n\r\nHere's the code, including some comments which show when compilation does fail as expected:\r\n\r\n\r\n{{{\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\n\r\nimport Data.IORef\r\n\r\nmain :: IO ()\r\nmain = do\r\n (r :: IORef (t -> t)) <- newIORef id\r\n -- r <- newIORef i -- => Type-check error\r\n\r\n writeIORef r (\\v -> if v then False else True)\r\n\r\n c <- readIORef r\r\n\r\n print $ c True\r\n\r\n print $ c 1234\r\n\r\n -- print $ c Nothing -- => Type-check error\r\n -- print $ c (1 :: Int) -- => Type-check error\r\n}}}\r\n\r\nWhen replacing the \"print $ c 1234\" line with one of the last 2 lines, type-checking fails.\r\nWhen removing the explicit type-annotation on 'r', type-checking fails when \"print $ c 1234\" is left in place.\r\n\r\nHere's the GHCi and GHC output:\r\n\r\n{{{\r\nPrelude> :load demo1.hs\r\n[1 of 1] Compiling Main ( demo1.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> main\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.0.4 for x86_64-unknown-linux):\r\n\tnameModule $dNum{v ann}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\n{{{\r\n$ ghc --make demo1.hs\r\n[1 of 1] Compiling Main ( demo1.hs, demo1.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.0.4 for x86_64-unknown-linux):\r\n\tinitC: srt_lbl\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5691Crash: strange interaction of ScopedTypeVariables extension with type class n...2019-07-07T18:54:01ZdominiquedevrieseCrash: strange interaction of ScopedTypeVariables extension with type class name resolutionI saw a compiler crash ("the 'impossible' happened..."), seemingly caused by a strange interaction of the ScopedTypeVariables GHC extension with type class name resolution. I am attaching a cut-down example showing the crash. I hope this...I saw a compiler crash ("the 'impossible' happened..."), seemingly caused by a strange interaction of the ScopedTypeVariables GHC extension with type class name resolution. I am attaching a cut-down example showing the crash. I hope this helps to find the bug. I have only tested with GHC 7.0.4; I am not sure if it is still present in later versions of the compiler. The crash occurs when I load the file in GHCi and evaluate the code
> parseRD (pure_ 'a') "a"
or when I simply try to compile the file from the command line.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.0.4 |
| 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":"Crash: strange interaction of ScopedTypeVariables extension with type class name resolution","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.4","keywords":["ScopedTypeVariables,","classes","type"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I saw a compiler crash (\"the 'impossible' happened...\"), seemingly caused by a strange interaction of the ScopedTypeVariables GHC extension with type class name resolution. I am attaching a cut-down example showing the crash. I hope this helps to find the bug. I have only tested with GHC 7.0.4; I am not sure if it is still present in later versions of the compiler. The crash occurs when I load the file in GHCi and evaluate the code \r\n\r\n parseRD (pure_ 'a') \"a\"\r\n\r\nor when I simply try to compile the file from the command line.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5736Possible regression with functional dependencies2019-07-07T18:53:49ZmagnusPossible regression with functional dependenciesThe following program typechecks in GHC-7.0.4, but not in 6.12.3, 7.2.2 or 7.5.20111229:
```
{-# LANGUAGE FunctionalDependencies, MultiParamTypeClasses,
FlexibleInstances, UndecidableInstances, TypeFamilies #-}
class C a b | a -> b ...The following program typechecks in GHC-7.0.4, but not in 6.12.3, 7.2.2 or 7.5.20111229:
```
{-# LANGUAGE FunctionalDependencies, MultiParamTypeClasses,
FlexibleInstances, UndecidableInstances, TypeFamilies #-}
class C a b | a -> b where
c :: a -> b
instance C b b where
c = undefined
instance C Bool b where
c = undefined
m :: Int
m = c True
```
1. 5.20111229 says
```
Couldn't match type `Bool' with `Int'
When using functional dependencies to combine
C b b,
arising from the dependency `a -> b'
in the instance declaration at Test.hs:7:10
C Bool Int, arising from a use of `c' at Test.hs:14:5
In the expression: c True
In an equation for `m': m = c True
```
Was I just lucky that this worked in 7.0.4, or is it a true regression?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.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":"Possible regression with functional dependencies","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program typechecks in GHC-7.0.4, but not in 6.12.3, 7.2.2 or 7.5.20111229:\r\n\r\n{{{\r\n{-# LANGUAGE FunctionalDependencies, MultiParamTypeClasses, \r\n FlexibleInstances, UndecidableInstances, TypeFamilies #-}\r\n\r\nclass C a b | a -> b where\r\n c :: a -> b\r\n\r\ninstance C b b where\r\n c = undefined\r\n\r\ninstance C Bool b where\r\n c = undefined\r\n\r\nm :: Int\r\nm = c True\r\n}}}\r\n\r\n7.5.20111229 says\r\n\r\n{{{\r\n Couldn't match type `Bool' with `Int'\r\n When using functional dependencies to combine\r\n C b b,\r\n arising from the dependency `a -> b'\r\n in the instance declaration at Test.hs:7:10\r\n C Bool Int, arising from a use of `c' at Test.hs:14:5\r\n In the expression: c True\r\n In an equation for `m': m = c True\r\n}}}\r\n\r\nWas I just lucky that this worked in 7.0.4, or is it a true regression?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5769Incorrect error message when compiling with PolyKinds and a type family2019-07-07T18:53:41ZRichard Eisenbergrae@richarde.devIncorrect error message when compiling with PolyKinds and a type familyWhen trying to compile
```
{-# LANGUAGE TypeFamilies,
PolyKinds,
ScopedTypeVariables
#-}
convert :: a -> b
convert = undefined
type family Foo a
bar :: forall b a. b -> (Foo a)
bar f = (convert f :: (Foo a)...When trying to compile
```
{-# LANGUAGE TypeFamilies,
PolyKinds,
ScopedTypeVariables
#-}
convert :: a -> b
convert = undefined
type family Foo a
bar :: forall b a. b -> (Foo a)
bar f = (convert f :: (Foo a))
```
I get the following error message:
```
Sandbox.hs:12:10:
Couldn't match type `Foo k a' with `Foo * b'
NB: `Foo' is a type function, and may not be injective
In the expression: (convert f :: Foo a)
In an equation for `bar': bar f = (convert f :: Foo a)
```
However, this compiles just fine without `PolyKinds`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.4.1-rc1 |
| 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":"Incorrect error message when compiling with PolyKinds and a type family","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1-rc1","keywords":["PolyKinds"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When trying to compile\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies,\r\n PolyKinds,\r\n ScopedTypeVariables\r\n #-}\r\n\r\nconvert :: a -> b\r\nconvert = undefined\r\n\r\ntype family Foo a\r\n\r\nbar :: forall b a. b -> (Foo a)\r\nbar f = (convert f :: (Foo a))\r\n}}}\r\n\r\nI get the following error message:\r\n{{{\r\nSandbox.hs:12:10:\r\n Couldn't match type `Foo k a' with `Foo * b'\r\n NB: `Foo' is a type function, and may not be injective\r\n In the expression: (convert f :: Foo a)\r\n In an equation for `bar': bar f = (convert f :: Foo a)\r\n}}}\r\n\r\nHowever, this compiles just fine without {{{PolyKinds}}}.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1dreixeldreixelhttps://gitlab.haskell.org/ghc/ghc/-/issues/5770Non-sensical error message when compiling with PolyKinds and a type family2019-07-07T18:53:40ZRichard Eisenbergrae@richarde.devNon-sensical error message when compiling with PolyKinds and a type familyWhen I compile the following code:
```
{-# LANGUAGE TypeFamilies,
PolyKinds,
ScopedTypeVariables
#-}
convert :: a -> b
convert = undefined
type family Foo a
type instance Foo Int = Bool
bar :: forall a b c...When I compile the following code:
```
{-# LANGUAGE TypeFamilies,
PolyKinds,
ScopedTypeVariables
#-}
convert :: a -> b
convert = undefined
type family Foo a
type instance Foo Int = Bool
bar :: forall a b c dummya. (b -> c) -> ((Foo a) -> c)
bar f = (convert f :: (Foo a) -> c)
```
I get the following error message:
```
Sandbox.hs:13:34:
Kind mis-match
Expected kind `OpenKind', but `c' has kind `b'
In an expression type signature: (Foo a) -> c
In the expression: (convert f :: (Foo a) -> c)
In an equation for `bar': bar f = (convert f :: (Foo a) -> c)
```
This error message does not make sense, for 'b' isn't a kind. It is interesting to note that removing `dummya` from the list of declared type variables changes the error to a GHC panic.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.4.1-rc1 |
| 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":"Non-sensical error message when compiling with PolyKinds and a type family","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1-rc1","keywords":["PolyKinds"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I compile the following code:\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies,\r\n PolyKinds,\r\n ScopedTypeVariables\r\n #-}\r\n\r\nconvert :: a -> b\r\nconvert = undefined\r\n\r\ntype family Foo a \r\ntype instance Foo Int = Bool\r\n\r\nbar :: forall a b c dummya. (b -> c) -> ((Foo a) -> c)\r\nbar f = (convert f :: (Foo a) -> c)\r\n}}}\r\n\r\nI get the following error message:\r\n\r\n{{{\r\nSandbox.hs:13:34:\r\n Kind mis-match\r\n Expected kind `OpenKind', but `c' has kind `b'\r\n In an expression type signature: (Foo a) -> c\r\n In the expression: (convert f :: (Foo a) -> c)\r\n In an equation for `bar': bar f = (convert f :: (Foo a) -> c)\r\n}}}\r\n\r\nThis error message does not make sense, for 'b' isn't a kind. It is interesting to note that removing {{{dummya}}} from the list of declared type variables changes the error to a GHC panic.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1dreixeldreixelhttps://gitlab.haskell.org/ghc/ghc/-/issues/5772Failed kind inference in class declaration (regression error)2019-07-07T18:53:40ZRichard Eisenbergrae@richarde.devFailed kind inference in class declaration (regression error)Consider the following code:
```
{-# LANGUAGE MultiParamTypeClasses
#-}
class Foo a b
class Foo a b => Bar a b where
baz :: a b
```
This compiles fine in 7.2.1 but fails in 7.4.1-rc1, with the following error:
```
Sandbox.hs:7:...Consider the following code:
```
{-# LANGUAGE MultiParamTypeClasses
#-}
class Foo a b
class Foo a b => Bar a b where
baz :: a b
```
This compiles fine in 7.2.1 but fails in 7.4.1-rc1, with the following error:
```
Sandbox.hs:7:12:
`a' is applied to too many type arguments
In the type `a b'
In the class declaration for `Bar'
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.4.1-rc1 |
| 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":"Failed kind inference in class declaration (regression error)","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following code:\r\n\r\n{{{\r\n{-# LANGUAGE MultiParamTypeClasses\r\n #-}\r\n\r\nclass Foo a b\r\n\r\nclass Foo a b => Bar a b where\r\n baz :: a b\r\n}}}\r\n\r\nThis compiles fine in 7.2.1 but fails in 7.4.1-rc1, with the following error:\r\n\r\n{{{\r\nSandbox.hs:7:12:\r\n `a' is applied to too many type arguments\r\n In the type `a b'\r\n In the class declaration for `Bar'\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5792PolyKinds and recompilation causes internal error2019-07-07T18:53:35ZreinerpPolyKinds and recompilation causes internal errorGiven these two files:
```
module A where
-- empty
```
and
```
{-# LANGUAGE PolyKinds, TypeFamilies, UndecidableInstances #-}
module B where
import A
data T = TT
type family Compare (m :: T) :: Ordering
type instance Compare TT = C...Given these two files:
```
module A where
-- empty
```
and
```
{-# LANGUAGE PolyKinds, TypeFamilies, UndecidableInstances #-}
module B where
import A
data T = TT
type family Compare (m :: T) :: Ordering
type instance Compare TT = Compare TT
type Compare' a = Compare a
```
We can cause an internal GHC error as follows:
```
$ rm *.o *.hi
$ ghc B.hs
[1 of 2] Compiling A ( A.hs, A.o )
[2 of 2] Compiling B ( B.hs, B.o )
$ sleep 1
$ touch B.hs
$ ghc B.hs
[2 of 2] Compiling B ( B.hs, B.o )
B.hs:11:19:
GHC internal error: `Compare' is not in scope during type checking, but it passed the renamer
tcl_env of environment: [(a9R, AThing k_a9U)]
In the type `Compare a'
In the type synonym declaration for Compare'
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.4.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"PolyKinds and recompilation causes internal error","status":"New","operating_system":"MacOS X","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Given these two files:\r\n{{{\r\nmodule A where\r\n-- empty\r\n}}}\r\n\r\nand\r\n\r\n{{{\r\n\r\n{-# LANGUAGE PolyKinds, TypeFamilies, UndecidableInstances #-}\r\nmodule B where\r\n\r\nimport A\r\n\r\ndata T = TT\r\n\r\ntype family Compare (m :: T) :: Ordering\r\ntype instance Compare TT = Compare TT\r\n\r\ntype Compare' a = Compare a\r\n}}}\r\n\r\nWe can cause an internal GHC error as follows:\r\n\r\n{{{\r\n$ rm *.o *.hi\r\n$ ghc B.hs\r\n[1 of 2] Compiling A ( A.hs, A.o )\r\n[2 of 2] Compiling B ( B.hs, B.o )\r\n$ sleep 1\r\n$ touch B.hs\r\n$ ghc B.hs\r\n[2 of 2] Compiling B ( B.hs, B.o )\r\n\r\nB.hs:11:19:\r\n GHC internal error: `Compare' is not in scope during type checking, but it passed the renamer\r\n tcl_env of environment: [(a9R, AThing k_a9U)]\r\n In the type `Compare a'\r\n In the type synonym declaration for Compare'\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/5798PolyKinds: couldn't match kind `BOX' against `*'2019-07-07T18:53:32ZreinerpPolyKinds: couldn't match kind `BOX' against `*'This module fails to compile:
```
{-# LANGUAGE PolyKinds #-}
module Test where
data Proxy t = ProxyC
test :: Proxy '[Int, Bool]
test = ProxyC -- doesn't compile
-- test = undefined -- compiles
```
The compilation error...This module fails to compile:
```
{-# LANGUAGE PolyKinds #-}
module Test where
data Proxy t = ProxyC
test :: Proxy '[Int, Bool]
test = ProxyC -- doesn't compile
-- test = undefined -- compiles
```
The compilation error is
```
Test.hs:8:8:
Couldn't match kind `BOX' against `*'
Kind incompatibility when matching types:
k0 :: BOX
[*] :: *
In the expression: ProxyC
In an equation for `test': test = ProxyC
```
However, this module is indeed well-typed, -sorted, and -kinded. The types and kinds should be as follows:
```
Proxy :: forall (k :: BOX). k -> *
ProxyC :: forall (k :: BOX). forall (t :: k). Proxy t
'[Int, Bool] :: [*]
[*] :: BOX
```
However, the error message suggests that GHC gives `[*]` the sort `*`, instead of `BOX`. This is wrong.
Note that the module compiles if `test = ProxyC` is replaced with `test = undefined`. So it seems that type-checking of type signature sets `[*] :: BOX`, whereas type-checking of the value expression sets `[*] :: *`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.4.1-rc1 |
| 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":"PolyKinds: couldn't match kind `BOX' against `*'","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1-rc1","keywords":["PolyKinds"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This module fails to compile:\r\n\r\n{{{\r\n{-# LANGUAGE PolyKinds #-}\r\n\r\nmodule Test where\r\n\r\ndata Proxy t = ProxyC\r\n\r\ntest :: Proxy '[Int, Bool]\r\ntest = ProxyC -- doesn't compile\r\n-- test = undefined -- compiles\r\n}}}\r\n\r\nThe compilation error is \r\n{{{\r\nTest.hs:8:8:\r\n Couldn't match kind `BOX' against `*'\r\n Kind incompatibility when matching types:\r\n k0 :: BOX\r\n [*] :: *\r\n In the expression: ProxyC\r\n In an equation for `test': test = ProxyC\r\n}}}\r\n\r\nHowever, this module is indeed well-typed, -sorted, and -kinded. The types and kinds should be as follows:\r\n\r\n{{{\r\nProxy :: forall (k :: BOX). k -> *\r\nProxyC :: forall (k :: BOX). forall (t :: k). Proxy t\r\n'[Int, Bool] :: [*]\r\n[*] :: BOX\r\n}}}\r\n\r\nHowever, the error message suggests that GHC gives {{{[*]}}} the sort {{{*}}}, instead of {{{BOX}}}. This is wrong.\r\n\r\nNote that the module compiles if {{{test = ProxyC}}} is replaced with {{{test = undefined}}}. So it seems that type-checking of type signature sets {{{[*] :: BOX}}}, whereas type-checking of the value expression sets {{{[*] :: *}}}.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/5802GHC Panic with PolyKinds and TypeFamilies2019-07-07T18:53:31ZdominiquedevrieseGHC Panic with PolyKinds and TypeFamiliesThe following crashes:
```
{-# LANGUAGE TypeOperators, PolyKinds, TypeFamilies, ExplicitForAll, GADTs #-}
module GHCBug where
data Nat = Zero | Succ Nat
data NatV (a :: Nat) where
ZeroV :: NatV Zero
SuccV :: NatV n ->...The following crashes:
```
{-# LANGUAGE TypeOperators, PolyKinds, TypeFamilies, ExplicitForAll, GADTs #-}
module GHCBug where
data Nat = Zero | Succ Nat
data NatV (a :: Nat) where
ZeroV :: NatV Zero
SuccV :: NatV n -> NatV (Succ n)
data Phantom t = Whoo
data ListV (a :: [*]) where
NilV :: ListV '[]
(:::) :: Phantom a -> ListV as -> ListV (a ': as)
type family (:+:) (a :: Nat) (b :: Nat) :: Nat
type instance Zero :+: b = b
type instance (Succ a) :+: b = Succ (a :+: b)
type family TReplicate (n :: Nat) (t :: *) :: [*]
type instance TReplicate Zero t = '[]
type instance TReplicate (Succ n) t = t ': TReplicate n t
replicateTList :: forall (n :: Nat). forall t.
NatV n -> Phantom t -> ListV (TReplicate n t)
replicateTList ZeroV _ = NilV
replicateTList (SuccV n) t = t ::: replicateTList n t
```
Potentially related to 5717 and 5768, although those two seem to be related to ScopedTypeVariables? They also seem to have a different panic message, although maybe this is because I'm using a debug-built GHC?
I'm not actually using 7.4.1-rc1, but 7.4 HEAD at the time of this writing.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.4.1-rc1 |
| 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":"GHC Panic with PolyKinds and TypeFamilies","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1-rc1","keywords":["PolyKinds"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following crashes:\r\n\r\n{{{\r\n {-# LANGUAGE TypeOperators, PolyKinds, TypeFamilies, ExplicitForAll, GADTs #-}\r\n\r\n module GHCBug where\r\n\r\n data Nat = Zero | Succ Nat\r\n\r\n data NatV (a :: Nat) where\r\n ZeroV :: NatV Zero\r\n SuccV :: NatV n -> NatV (Succ n)\r\n\r\n data Phantom t = Whoo\r\n\r\n data ListV (a :: [*]) where\r\n NilV :: ListV '[]\r\n (:::) :: Phantom a -> ListV as -> ListV (a ': as)\r\n\r\n type family (:+:) (a :: Nat) (b :: Nat) :: Nat\r\n type instance Zero :+: b = b\r\n type instance (Succ a) :+: b = Succ (a :+: b)\r\n\r\n type family TReplicate (n :: Nat) (t :: *) :: [*]\r\n type instance TReplicate Zero t = '[]\r\n type instance TReplicate (Succ n) t = t ': TReplicate n t\r\n\r\n replicateTList :: forall (n :: Nat). forall t.\r\n\t\t NatV n -> Phantom t -> ListV (TReplicate n t)\r\n replicateTList ZeroV _ = NilV\r\n replicateTList (SuccV n) t = t ::: replicateTList n t\r\n}}}\r\n\r\nPotentially related to 5717 and 5768, although those two seem to be related to ScopedTypeVariables? They also seem to have a different panic message, although maybe this is because I'm using a debug-built GHC?\r\n\r\nI'm not actually using 7.4.1-rc1, but 7.4 HEAD at the time of this writing.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5837Context reduction stack overflow can take very long2019-07-07T18:53:23ZdreixelContext reduction stack overflow can take very longThe following code, taken from the "Haskell Type Constraints Unleashed" paper:
```
{-# LANGUAGE TypeFamilies #-}
type family TF a :: *
type instance TF (a,b) = (TF a, TF b)
t :: (a ~ TF (a,Int)) => Int
t = undefined
```
fails almost ...The following code, taken from the "Haskell Type Constraints Unleashed" paper:
```
{-# LANGUAGE TypeFamilies #-}
type family TF a :: *
type instance TF (a,b) = (TF a, TF b)
t :: (a ~ TF (a,Int)) => Int
t = undefined
```
fails almost immediately with `Context reduction stack overflow` on GHC 7.2, but seems to loop forever with 7.4.1-rc2. Setting `-fcontext-stack` to `20` results in near immediate termination with the same error. But #5395 raised the context stack size default to `200`, which makes this code (that does not use `-XUndecidableInstances`) take "forever" to compile.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.4.1-rc2 |
| 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":"Context reduction stack overflow can take very long","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code, taken from the \"Haskell Type Constraints Unleashed\" paper:\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\ntype family TF a :: *\r\ntype instance TF (a,b) = (TF a, TF b)\r\n\r\nt :: (a ~ TF (a,Int)) => Int\r\nt = undefined\r\n}}}\r\nfails almost immediately with `Context reduction stack overflow` on GHC 7.2, but seems to loop forever with 7.4.1-rc2. Setting `-fcontext-stack` to `20` results in near immediate termination with the same error. But #5395 raised the context stack size default to `200`, which makes this code (that does not use `-XUndecidableInstances`) take \"forever\" to compile.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/5927A type-level "implies" constraint on Constraints2020-02-05T20:35:11ZillissiusA type-level "implies" constraint on ConstraintsI have a datatype:
```
data Exists c where Exists :: c a => a -> Exists c
```
I have an instance for it:
```
instance Show (Exists Show) where
show (Exists a) = show a
```
And that's alright, as far as it goes: any Exists Show ca...I have a datatype:
```
data Exists c where Exists :: c a => a -> Exists c
```
I have an instance for it:
```
instance Show (Exists Show) where
show (Exists a) = show a
```
And that's alright, as far as it goes: any Exists Show can indeed itself be shown. But I want more. I want to be able to say:
```
instance (c `Implies` Show) => Show (Exists c) where
show (Exists a) = show a
```
In other words, I want to be able to say that any (Exists c) where the constraint c implies Show can be shown. For example, if Num still had a Show constraint, I wouldn't want to have to write a separate instance Show (Exists Num) to be able to show an Exists Num; I would want to be able to write a single instance (along the lines of the above) which works for both.
GHC clearly has this information: it lets me use a function of type `forall a. Eq a => a -> r` as one of type `forall a. Ord a => a -> r`, but not vice versa, so it knows that Ord implies Eq, but not vice versa. I've attached a file which demonstrates this and a couple of other examples.
What's not completely clear to me is what would be the appropriate way to be able to ask it about this. An Implies constraint to parallel the (\~) constraint would work, but with what syntax? (Just straightforwardly call it Implies?) And what semantics -- what would be the kind of Implies? It's notable that in the above example its arguments aren't of type Constraint, but rather \* -\> Constraint, and for (\* -\> \*) -\> Constraint it could similarly work, and with MPTCs \* -\> \* -\> Constraint and (\* -\> \*) -\> (\* -\> \*) -\> Constraint and \* -\> (\* -\> \*) -\> Constraint and so on probably also make sense... but I have no idea how to formalize this, where the boundaries lie, and whether it makes any kind of sense. I can try to think harder about it if that would help, but hopefully the outlines of the situation are more immediately obvious to someone on the GHC team.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.4.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":"A type-level \"implies\" constraint on Constraints","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I have a datatype:\r\n\r\n{{{\r\ndata Exists c where Exists :: c a => a -> Exists c\r\n}}}\r\n\r\nI have an instance for it:\r\n\r\n{{{\r\ninstance Show (Exists Show) where\r\n show (Exists a) = show a\r\n}}}\r\n\r\nAnd that's alright, as far as it goes: any Exists Show can indeed itself be shown. But I want more. I want to be able to say:\r\n\r\n{{{\r\ninstance (c `Implies` Show) => Show (Exists c) where\r\n show (Exists a) = show a\r\n}}}\r\n\r\nIn other words, I want to be able to say that any (Exists c) where the constraint c implies Show can be shown. For example, if Num still had a Show constraint, I wouldn't want to have to write a separate instance Show (Exists Num) to be able to show an Exists Num; I would want to be able to write a single instance (along the lines of the above) which works for both.\r\n\r\nGHC clearly has this information: it lets me use a function of type {{{forall a. Eq a => a -> r}}} as one of type {{{forall a. Ord a => a -> r}}}, but not vice versa, so it knows that Ord implies Eq, but not vice versa. I've attached a file which demonstrates this and a couple of other examples.\r\n\r\nWhat's not completely clear to me is what would be the appropriate way to be able to ask it about this. An Implies constraint to parallel the (~) constraint would work, but with what syntax? (Just straightforwardly call it Implies?) And what semantics -- what would be the kind of Implies? It's notable that in the above example its arguments aren't of type Constraint, but rather * -> Constraint, and for (* -> *) -> Constraint it could similarly work, and with MPTCs * -> * -> Constraint and (* -> *) -> (* -> *) -> Constraint and * -> (* -> *) -> Constraint and so on probably also make sense... but I have no idea how to formalize this, where the boundaries lie, and whether it makes any kind of sense. I can try to think harder about it if that would help, but hopefully the outlines of the situation are more immediately obvious to someone on the GHC team.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/5935Failure to resolve AnyK2019-07-07T18:52:56ZRichard Eisenbergrae@richarde.devFailure to resolve AnyKConsider the following code:
```
{-# LANGUAGE PolyKinds,
GADTs,
DataKinds,
KindSignatures
#-}
data SList a where
SNil :: SList '[]
x :: SList ('[] :: [Bool])
x = SNil
```
Compiling this code ...Consider the following code:
```
{-# LANGUAGE PolyKinds,
GADTs,
DataKinds,
KindSignatures
#-}
data SList a where
SNil :: SList '[]
x :: SList ('[] :: [Bool])
x = SNil
```
Compiling this code causes GHC to emit an error saying that `AnyK` cannot be unified with `Bool`. It seems that `AnyK` is a placeholder for an undetermined kind and that it should unify with any well-formed kind.
As a much smaller issue, the error emitted speaks about "types" where it means "kinds".
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.4.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":"Failure to resolve AnyK","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":["DataKinds","PolyKinds"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following code:\r\n\r\n{{{\r\n{-# LANGUAGE PolyKinds,\r\n GADTs,\r\n DataKinds,\r\n KindSignatures\r\n #-}\r\n\r\ndata SList a where\r\n SNil :: SList '[]\r\n\r\nx :: SList ('[] :: [Bool])\r\nx = SNil\r\n}}}\r\n\r\nCompiling this code causes GHC to emit an error saying that {{{AnyK}}} cannot be unified with {{{Bool}}}. It seems that {{{AnyK}}} is a placeholder for an undetermined kind and that it should unify with any well-formed kind.\r\n\r\nAs a much smaller issue, the error emitted speaks about \"types\" where it means \"kinds\".","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5937Kind variables not allowed in data declaration kind annotation2019-07-07T18:52:55ZRichard Eisenbergrae@richarde.devKind variables not allowed in data declaration kind annotationGHC won't accept kind variables stated directly in a data declaration. For example, the following does not compile:
```
data SMaybe :: (k -> *) -> Maybe k -> * where
SNothing :: SMaybe s 'Nothing
SJust :: s a -> SMaybe s ('Just a)
`...GHC won't accept kind variables stated directly in a data declaration. For example, the following does not compile:
```
data SMaybe :: (k -> *) -> Maybe k -> * where
SNothing :: SMaybe s 'Nothing
SJust :: s a -> SMaybe s ('Just a)
```
However, the following does compile:
```
data SMaybe' (s :: k -> *) (m :: Maybe k) where
SNothing' :: SMaybe' s 'Nothing
SJust' :: s a -> SMaybe' s ('Just a)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.5 |
| 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":"Kind variables not allowed in data declaration kind annotation","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.5","keywords":["PolyKinds"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC won't accept kind variables stated directly in a data declaration. For example, the following does not compile:\r\n\r\n{{{\r\ndata SMaybe :: (k -> *) -> Maybe k -> * where\r\n SNothing :: SMaybe s 'Nothing\r\n SJust :: s a -> SMaybe s ('Just a)\r\n}}}\r\n\r\nHowever, the following does compile:\r\n\r\n{{{\r\ndata SMaybe' (s :: k -> *) (m :: Maybe k) where\r\n SNothing' :: SMaybe' s 'Nothing\r\n SJust' :: s a -> SMaybe' s ('Just a)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5938Kind variables not allowed in type family instance declarations2019-07-07T18:52:55ZRichard Eisenbergrae@richarde.devKind variables not allowed in type family instance declarationsI am trying to create a kind-indexed type family, but I cannot use kind variables in my kind annotations:
```
{-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-}
type family KindFam a
type instance KindFam (a :: *) = Int
type instance ...I am trying to create a kind-indexed type family, but I cannot use kind variables in my kind annotations:
```
{-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-}
type family KindFam a
type instance KindFam (a :: *) = Int
type instance KindFam (a :: Bool) = Bool
type instance KindFam (a :: Maybe k) = Char -- doesn't work
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.5 |
| 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":"Kind variables not allowed in type family instance declarations","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I am trying to create a kind-indexed type family, but I cannot use kind variables in my kind annotations:\r\n\r\n{{{\r\n{-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-}\r\n\r\ntype family KindFam a\r\ntype instance KindFam (a :: *) = Int\r\ntype instance KindFam (a :: Bool) = Bool\r\ntype instance KindFam (a :: Maybe k) = Char -- doesn't work\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5952Extra ' in error output concerning promoted kinds2019-07-07T18:52:52ZRichard Eisenbergrae@richarde.devExtra ' in error output concerning promoted kindsWhen I try to compile the following code, a slightly erroneous error message is produced:
```
{-# LANGUAGE DataKinds #-}
foo :: 'False
foo = undefined
```
The error message is
```
Kind mis-match
Expected kind `ArgKind', but `False' h...When I try to compile the following code, a slightly erroneous error message is produced:
```
{-# LANGUAGE DataKinds #-}
foo :: 'False
foo = undefined
```
The error message is
```
Kind mis-match
Expected kind `ArgKind', but `False' has kind 'Bool
In the type signature for `foo': foo :: False
```
The problem is that the kind of `'False` is reported as `'Bool`. However, if you use a kind written `'Bool` in a program, that program fails to compile. As I understand it, the only way to write the kind of `'False` is `Bool`, without the initial tick.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.5 |
| 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":"Extra ' in error output concerning promoted kinds","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.5","keywords":["DataKinds"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I try to compile the following code, a slightly erroneous error message is produced:\r\n\r\n{{{\r\n{-# LANGUAGE DataKinds #-}\r\n\r\nfoo :: 'False\r\nfoo = undefined\r\n}}}\r\n\r\nThe error message is\r\n\r\n{{{\r\nKind mis-match\r\nExpected kind `ArgKind', but `False' has kind 'Bool\r\nIn the type signature for `foo': foo :: False\r\n}}}\r\n\r\nThe problem is that the kind of {{{'False}}} is reported as {{{'Bool}}}. However, if you use a kind written {{{'Bool}}} in a program, that program fails to compile. As I understand it, the only way to write the kind of {{{'False}}} is {{{Bool}}}, without the initial tick.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5957signatures are too permissive2019-07-07T18:52:51ZChristian Maedersignatures are too permissiveghc should reject the following (accidentally mistyped) signature, unless `-XFlexibleContexts` is used.
```
flex :: Int -> Show a => a -> String
flex i a = show a ++ show i
```
hugs and ghc version below 7 rejected this correctly:
```...ghc should reject the following (accidentally mistyped) signature, unless `-XFlexibleContexts` is used.
```
flex :: Int -> Show a => a -> String
flex i a = show a ++ show i
```
hugs and ghc version below 7 rejected this correctly:
```
All of the type variables in the constraint `Show a'
are already in scope (at least one must be universally quantified here)
(Use -XFlexibleContexts to lift this restriction)
In the type signature for `flex':
flex :: Int -> (Show a) => a -> String
```
It is not Haskell98 nor Haskell2010 (I believe).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.4.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":"signatures are too permissive","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ghc should reject the following (accidentally mistyped) signature, unless `-XFlexibleContexts` is used.\r\n\r\n{{{\r\nflex :: Int -> Show a => a -> String\r\nflex i a = show a ++ show i\r\n}}}\r\n\r\nhugs and ghc version below 7 rejected this correctly:\r\n\r\n{{{\r\n All of the type variables in the constraint `Show a'\r\n are already in scope (at least one must be universally quantified here)\r\n (Use -XFlexibleContexts to lift this restriction)\r\n In the type signature for `flex':\r\n flex :: Int -> (Show a) => a -> String\r\n}}}\r\n\r\nIt is not Haskell98 nor Haskell2010 (I believe).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5970Type checker hangs2019-07-07T18:52:47ZLemmingType checker hangsWhen compiling my synthesizer-llvm package, GHC-7.4.1 hangs in the type checking phase for the module
http://code.haskell.org/synthesizer/llvm/src/Synthesizer/LLVM/Server/Packed/Instrument.hs
This module always needed more than a minute...When compiling my synthesizer-llvm package, GHC-7.4.1 hangs in the type checking phase for the module
http://code.haskell.org/synthesizer/llvm/src/Synthesizer/LLVM/Server/Packed/Instrument.hs
This module always needed more than a minute for type-checking in GHC-7.2.2 and before. I guess this was because it is a module where functions with a lot of type-level arithmetic from the type-level package are applied to values of concrete types. Maybe with GHC-7.4.1 the compilation time simply became even longer - at least several minutes.
I tried to simplify the example and reduce the dependencies. This is not so simple because reducing the module size also decreases type checking time and when drastically simplified the compilation time for that module is ok. Now I am trying to construct an example where I repeat the same (simple) function definition. I already observed that repeating a function definition n times does not multiply the type checking by n but it needs considerably more time. I think this can be considered a bug.
I am investigating further. If you have some advice, I like to know. Maybe you remember a 'foldl' that should be a 'foldr' in the type checker, that may cause a quadratic type checking time ... If so then this would be a good opportunity to fix it. ;-)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.4.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":"Type checker hangs","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When compiling my synthesizer-llvm package, GHC-7.4.1 hangs in the type checking phase for the module\r\nhttp://code.haskell.org/synthesizer/llvm/src/Synthesizer/LLVM/Server/Packed/Instrument.hs\r\n\r\nThis module always needed more than a minute for type-checking in GHC-7.2.2 and before. I guess this was because it is a module where functions with a lot of type-level arithmetic from the type-level package are applied to values of concrete types. Maybe with GHC-7.4.1 the compilation time simply became even longer - at least several minutes.\r\n\r\nI tried to simplify the example and reduce the dependencies. This is not so simple because reducing the module size also decreases type checking time and when drastically simplified the compilation time for that module is ok. Now I am trying to construct an example where I repeat the same (simple) function definition. I already observed that repeating a function definition n times does not multiply the type checking by n but it needs considerably more time. I think this can be considered a bug.\r\n\r\nI am investigating further. If you have some advice, I like to know. Maybe you remember a 'foldl' that should be a 'foldr' in the type checker, that may cause a quadratic type checking time ... If so then this would be a good opportunity to fix it. ;-)\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5978Type error in one function causes wrong type error report in another function...2019-07-07T18:52:44ZLemmingType error in one function causes wrong type error report in another function in the presence of functionally dependent typesWhen trying to reduce my problem in #5970 to a simple program I encountered an even more obvious bug. The problem is essentially as follows: I have
```
correct :: T
correct = ...
wrong :: T
wrong = f correct
```
where 'wrong' has a ty...When trying to reduce my problem in #5970 to a simple program I encountered an even more obvious bug. The problem is essentially as follows: I have
```
correct :: T
correct = ...
wrong :: T
wrong = f correct
```
where 'wrong' has a type error and 'correct' is type correct. If I outcomment 'wrong' then GHC correctly confirms type-correctness of 'correct', but if 'wrong' is enabled then GHC claims a type error in both 'wrong' and 'correct'.
To me it looks like the type-checker is trying to unify types across function boundaries. This would explain both non-linear growth of type-checking time and the observed effect of incorrect type errors.
See attached program for a working example.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.4.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":"Type error in one function causes wrong type error report in another function in the presence of functionally dependent types","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When trying to reduce my problem in #5970 to a simple program I encountered an even more obvious bug. The problem is essentially as follows: I have\r\n{{{\r\ncorrect :: T\r\ncorrect = ...\r\n\r\nwrong :: T\r\nwrong = f correct\r\n}}}\r\nwhere 'wrong' has a type error and 'correct' is type correct. If I outcomment 'wrong' then GHC correctly confirms type-correctness of 'correct', but if 'wrong' is enabled then GHC claims a type error in both 'wrong' and 'correct'.\r\nTo me it looks like the type-checker is trying to unify types across function boundaries. This would explain both non-linear growth of type-checking time and the observed effect of incorrect type errors.\r\nSee attached program for a working example.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/6013the 'impossible' happened2019-07-07T18:52:35Ztlvbthe 'impossible' happenedPlease forgive me if this is a duplicate or irrelevant, bug reporting and Haskell are two things I work with seldom enough that I cannot be considered good at either, but as what happened should be 'impossible' I thought I'd at least giv...Please forgive me if this is a duplicate or irrelevant, bug reporting and Haskell are two things I work with seldom enough that I cannot be considered good at either, but as what happened should be 'impossible' I thought I'd at least give you a heads up. I tried looking for similar bugs, but I do not really know what I would be looking for...
GHCi (newly opened, -v flag):
```
[leo@derse brutelift]$ ghci -v
GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help
Glasgow Haskell Compiler, Version 7.4.1, stage 2 booted by GHC version 7.4.1
Using binary package database: /usr/lib/ghc-7.4.1/package.conf.d/package.cache
wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-c2ff696e5b8ec4d4b2bc2e42085fe471
wired-in package integer-gmp mapped to integer-gmp-0.4.0.0-3cccac07aef8e27023f605c1f45bdf74
wired-in package base mapped to base-4.5.0.0-40b99d05fae6a4eea95ea69e6e0c9702
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.7.0.0-8c8cd20e21666657195efabced685fe1
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags: -static
Loading package ghc-prim ... linking ... done.
*** gcc:
'/usr/bin/gcc' '-fno-stack-protector' '-Wl,--hash-size=31' '-Wl,--reduce-memory-overheads' '-L/usr/lib/ghc-7.4.1/integer-gmp-0.4.0.0' '--print-file-name' 'libgmp.so'
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :load brutelift
*** Chasing dependencies:
Chasing modules from:
Stable obj: []
Stable BCO: []
unload: retaining objs []
unload: retaining bcos []
Ready for upsweep []
Upsweep completely successful.
*** Deleting temp files:
Deleting:
*** Chasing dependencies:
Chasing modules from: *brutelift.hs
Stable obj: []
Stable BCO: []
unload: retaining objs []
unload: retaining bcos []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = Tue Apr 17 18:10:32 CEST 2012
ms_mod = main:Main,
ms_textual_imps = [import (implicit) Prelude, import Data.List]
ms_srcimps = []
}]
*** Deleting temp files:
Deleting:
compile: input file brutelift.hs
Created temporary directory: /tmp/ghc5399_0
*** Checking old interface for main:Main:
[1 of 1] Compiling Main ( brutelift.hs, interpreted )
*** Parser:
*** Renamer/typechecker:
ghc: panic! (the 'impossible' happened)
(GHC version 7.4.1 for x86_64-unknown-linux):
nameModule show{tv abQ}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
```
brutelift.hs:
```
import Data.List
data Transfer = Load | Unload
data Action = Left Transfer Int | Right Transfer Int
data BlockDispersion = Blocks {top :: [Int]
, bottom :: [Int]
, left :: [Int]
, right :: [Int]}
deriving (Show)
data Machine = MOK BlockDispersion [Action] | MError BlockDispersion [Action] deriving (show)
rSplitAt i xs = let (a, b) = splitAt i $ reverse xs in
(reverse b, reverse a)
moveR :: Int -> ([a], [a]) -> ([a], [a])
moveR i (a, b) = let (c, d) = rSplitAt i a
in (c, d++b)
moveL :: Int -> ([a], [a]) -> ([a], [a])
moveL i (a, b) = let (c, d) = splitAt i b
in (a++c, d)
```
I am not sure what additional info to provide...
Running an Arch linux system, 8GB ram, installed ghc packgage should be as vanilla as can be...
```
[leo@derse brutelift]$ uname -a
Linux derse 3.3.1-1-ARCH #1 SMP PREEMPT Tue Apr 3 06:46:17 UTC 2012 x86_64 Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz GenuineIntel GNU/Linux
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | GhciCrash |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"the 'impossible' happened","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":["checker,","impossible,","panic,","renamer","type"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Please forgive me if this is a duplicate or irrelevant, bug reporting and Haskell are two things I work with seldom enough that I cannot be considered good at either, but as what happened should be 'impossible' I thought I'd at least give you a heads up. I tried looking for similar bugs, but I do not really know what I would be looking for...\r\n\r\nGHCi (newly opened, -v flag):\r\n{{{\r\n[leo@derse brutelift]$ ghci -v\r\nGHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help\r\nGlasgow Haskell Compiler, Version 7.4.1, stage 2 booted by GHC version 7.4.1\r\nUsing binary package database: /usr/lib/ghc-7.4.1/package.conf.d/package.cache\r\nwired-in package ghc-prim mapped to ghc-prim-0.2.0.0-c2ff696e5b8ec4d4b2bc2e42085fe471\r\nwired-in package integer-gmp mapped to integer-gmp-0.4.0.0-3cccac07aef8e27023f605c1f45bdf74\r\nwired-in package base mapped to base-4.5.0.0-40b99d05fae6a4eea95ea69e6e0c9702\r\nwired-in package rts mapped to builtin_rts\r\nwired-in package template-haskell mapped to template-haskell-2.7.0.0-8c8cd20e21666657195efabced685fe1\r\nwired-in package dph-seq not found.\r\nwired-in package dph-par not found.\r\nHsc static flags: -static\r\nLoading package ghc-prim ... linking ... done.\r\n*** gcc:\r\n'/usr/bin/gcc' '-fno-stack-protector' '-Wl,--hash-size=31' '-Wl,--reduce-memory-overheads' '-L/usr/lib/ghc-7.4.1/integer-gmp-0.4.0.0' '--print-file-name' 'libgmp.so'\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nPrelude> :load brutelift\r\n*** Chasing dependencies:\r\nChasing modules from: \r\nStable obj: []\r\nStable BCO: []\r\nunload: retaining objs []\r\nunload: retaining bcos []\r\nReady for upsweep []\r\nUpsweep completely successful.\r\n*** Deleting temp files:\r\nDeleting: \r\n*** Chasing dependencies:\r\nChasing modules from: *brutelift.hs\r\nStable obj: []\r\nStable BCO: []\r\nunload: retaining objs []\r\nunload: retaining bcos []\r\nReady for upsweep\r\n [NONREC\r\n ModSummary {\r\n ms_hs_date = Tue Apr 17 18:10:32 CEST 2012\r\n ms_mod = main:Main,\r\n ms_textual_imps = [import (implicit) Prelude, import Data.List]\r\n ms_srcimps = []\r\n }]\r\n*** Deleting temp files:\r\nDeleting: \r\ncompile: input file brutelift.hs\r\nCreated temporary directory: /tmp/ghc5399_0\r\n*** Checking old interface for main:Main:\r\n[1 of 1] Compiling Main ( brutelift.hs, interpreted )\r\n*** Parser:\r\n*** Renamer/typechecker:\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.4.1 for x86_64-unknown-linux):\r\n\tnameModule show{tv abQ}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n>\r\n}}}\r\n\r\nbrutelift.hs:\r\n\r\n{{{\r\nimport Data.List\r\n\r\ndata Transfer = Load | Unload\r\ndata Action = Left Transfer Int | Right Transfer Int\r\n\r\ndata BlockDispersion = Blocks {top :: [Int]\r\n\t\t\t\t, bottom :: [Int]\r\n\t\t\t\t, left :: [Int]\r\n\t\t\t\t, right :: [Int]}\r\n\t\t\t\tderiving (Show)\r\n\r\ndata Machine = MOK BlockDispersion [Action] | MError BlockDispersion [Action] deriving (show)\r\n\r\n\r\nrSplitAt i xs = let (a, b) = splitAt i $ reverse xs in\r\n\t(reverse b, reverse a)\r\n\t\r\nmoveR :: Int -> ([a], [a]) -> ([a], [a])\r\nmoveR i (a, b) = let (c, d) = rSplitAt i a\r\n\t\t\tin (c, d++b)\r\nmoveL :: Int -> ([a], [a]) -> ([a], [a])\r\nmoveL i (a, b) = let (c, d) = splitAt i b\r\n\t\t\tin (a++c, d)\r\n}}}\r\n\r\n\r\nI am not sure what additional info to provide...\r\nRunning an Arch linux system, 8GB ram, installed ghc packgage should be as vanilla as can be...\r\n\r\n{{{\r\n[leo@derse brutelift]$ uname -a\r\nLinux derse 3.3.1-1-ARCH #1 SMP PREEMPT Tue Apr 3 06:46:17 UTC 2012 x86_64 Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz GenuineIntel GNU/Linux\r\n}}}\r\n\r\n","type_of_failure":"GhciCrash","blocking":[]} -->7.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/6024Allow defining kinds alone, without a datatype2023-01-23T13:00:38ZdreixelAllow defining kinds alone, without a datatypeSometimes we want to define a kind alone, and we are not interested in the datatype. In principle having an extra datatype around is not a big problem, but the constructor names will be taken, so they cannot be used somewhere else. A con...Sometimes we want to define a kind alone, and we are not interested in the datatype. In principle having an extra datatype around is not a big problem, but the constructor names will be taken, so they cannot be used somewhere else. A contrived example:
```
data Code = Unit | Prod Code Code
data family Interprt (c :: Code) :: *
data instance Interprt Unit = Unit1
data instance Interprt (Prod a b) = Prod1 (Interprt a) (Interprt b)
```
We're only interested in the constructors of the data family `Interprt`, but we cannot use the names `Unit` and `Prod` because they are constructors of `Code`.
The suggestion is to allow defining:
```
data kind Code = Unit | Prod Code Code
```
Such that `Code` is a kind, and not a type, and `Unit` and `Prod` are types, and not constructors.
Note that using "data kind" instead of just "kind" means the word "kind" does not have to be a reserved keyword.
You could also think you would want to have datatypes that should not be promoted:
```
data K
data type T = K
```
But I don't see a need for this, as the fact that the `K` constructor is promoted to a type does not prevent you from having a datatype named `K`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.5 |
| 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":"Allow defining kinds alone, without a datatype","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Sometimes we want to define a kind alone, and we are not interested in the datatype. In principle having an extra datatype around is not a big problem, but the constructor names will be taken, so they cannot be used somewhere else. A contrived example:\r\n{{{\r\ndata Code = Unit | Prod Code Code\r\n\r\ndata family Interprt (c :: Code) :: *\r\ndata instance Interprt Unit = Unit1\r\ndata instance Interprt (Prod a b) = Prod1 (Interprt a) (Interprt b)\r\n}}}\r\nWe're only interested in the constructors of the data family `Interprt`, but we cannot use the names `Unit` and `Prod` because they are constructors of `Code`.\r\n\r\nThe suggestion is to allow defining:\r\n{{{\r\ndata kind Code = Unit | Prod Code Code\r\n}}}\r\nSuch that `Code` is a kind, and not a type, and `Unit` and `Prod` are types, and not constructors.\r\n\r\nNote that using \"data kind\" instead of just \"kind\" means the word \"kind\" does not have to be a reserved keyword.\r\n\r\nYou could also think you would want to have datatypes that should not be promoted:\r\n{{{\r\ndata K\r\n\r\ndata type T = K\r\n}}}\r\nBut I don't see a need for this, as the fact that the `K` constructor is promoted to a type does not prevent you from having a datatype named `K`.","type_of_failure":"OtherFailure","blocking":[]} -->Alexis WilliamsAlexis Williams