Attached file pluginbug.hs
($1237).
Attached file MyPlugin.hs
($1236).
Attached file error.txt
(download).
Attached file ring_bug.hs
($1215).
Attached file core7
(download).
2147483647 case
Attached file core8
(download).
2147483648 case
The GHC docs for GeneralisedNewtypeDeriving at (https://downloads.haskell.org/\~ghc/latest/docs/html/users_guide/glasgow_exts.html\#generalisedderivedinstancesfornewtypes) suggest British spelling should be accepted, and indeed it's the preferred spelling in the docs. However GHC 8.2 throws an error. I haven't tested this against HEAD so if it's fixed there please feel free to close.
I know this is a bit picky but it's caught me out a few times and I couldn't see it previously reported (I may have missed it though).
Trac field  Value 

Version  8.2.2 
Type  Bug 
TypeOfFailure  OtherFailure 
Priority  lowest 
Resolution  Unresolved 
Component  Compiler 
Test case  
Differential revisions  
BlockedBy  
Related  
Blocking  
CC  
Operating system  
Architecture 
Is there a tutorial/readme on adding benchmarks to NoFib?
Not sure if this is a bug in 'monotraversable' or GHC but I thought it was worth reporting in any case. GHC head 8.1.20170209 is the version used:
Configuring monotraversable1.0.1.1...
Preprocessing library monotraversable1.0.1.1...
[1 of 5] Compiling Data.MonoTraversable ( src/Data/MonoTraversable.hs, .stackwork/dist/x86_64linux/Cabal1.25.0.0/build/Data/MonoTraversable.o )
/tmp/stack12856/monotraversable1.0.1.1/src/Data/MonoTraversable.hs:144:13: error:
• The default type signature for omap:
forall (f :: * > *) a.
(Functor f, Element (f a) ~ a, f a ~ mono) =>
(a > a) > f a > f a
does not match its corresponding nondefault type signature
• When checking the class method:
omap :: forall mono.
MonoFunctor mono =>
(Element mono > Element mono) > mono > mono
In the class declaration for ‘MonoFunctor’

144  default omap :: (Functor f, Element (f a) ~ a, f a ~ mono) => (a > a) > f a > f a
 ^^^^
Trac field  Value 

Version  8.1 
Type  Bug 
TypeOfFailure  OtherFailure 
Priority  normal 
Resolution  Unresolved 
Component  Compiler 
Test case  
Differential revisions  
BlockedBy  
Related  
Blocking  
CC  
Operating system  
Architecture 
@simonpj: I'm not sure if I should put in a separate bug report or if I'm completely confused, but when I compile the following:
{# LANGUAGE TypeFamilyDependencies #}
type family F x = t  t > x
myId :: (F a ~ F b) => a > b
myId = id
main = pure ()
I get the error:
Could not deduce: a ~ b
from the context: F a ~ F b
Isn't this what ticket #10833 discusses, namely that GHC does not derive a ~ b
from F a ~ F b
?
Ah that makes sense presumably even injectivity won't help here as we can't derive a ~ b
from F a ~ F b
, even if F is injective yes?
Thank you for the explanation, but why does the code happily compile when type T m = D m
? Your explanation above seems independent of the exact definition of T
, so is there an alternate bug for the type T m = D m
case where the code compiles when it shouldn't?
Trac field  Value 

Version  8.1 → 8.0.1 
I think (but I'm not sure) that the following code should type check. This will require using the 'vector' package to illustrate this issue, sorry I couldn't create an example without it.
Either uncommenting the explicit m ()
signature or changing the type to the simpler D m
data type will allow the code to compile.
{# LANGUAGE ImplicitParams #}
{# LANGUAGE ScopedTypeVariables #}
{# LANGUAGE KindSignatures #}
import Data.Vector.Unboxed.Mutable (MVector)
import Control.Monad.Primitive (PrimMonad, PrimState)
data D (x :: * > *)
type T m = MVector (PrimState m) Int
type T m = D m
h :: forall m. PrimMonad m => T m > m ()
h x = let f _ = (let ?v = x in g) { :: m () } in f undefined
g :: (PrimMonad m , ?v :: T m) => m ()
g = undefined
main = pure ()
Alternatively, including g
into the let binding as opposed to the top level will also compile:
{# LANGUAGE ImplicitParams #}
{# LANGUAGE ScopedTypeVariables #}
{# LANGUAGE KindSignatures #}
import Data.Vector.Unboxed.Mutable (MVector)
import Control.Monad.Primitive (PrimMonad, PrimState)
data D (x :: * > *)
type T m = MVector (PrimState m) Int
type T m = D m
h :: forall m. PrimMonad m => T m > m ()
h x =
let
f _ = (let ?v = x in g) { :: m () }
g :: (PrimMonad m , ?v :: T m) => m ()
g = undefined
in f undefined
main = pure ()
Perhaps this isn't a bug and has to do with the rank2 type inside of Vector, but I'm just putting in this bug report to confirm.
This is an issue as of 8.0.2rc2.
Trac field  Value 

Version  8.0.2rc2 
Type  Bug 
TypeOfFailure  OtherFailure 
Priority  normal 
Resolution  Unresolved 
Component  Compiler 
Test case  
Differential revisions  
BlockedBy  
Related  
Blocking  
CC  
Operating system  
Architecture 
Trac field  Value 

Version  8.0.1 → 8.1 
The following has been compiled against ghc version 8.1.20161022, my apologies if this bug has already been fixed.
The following program compiles fine:
{# LANGUAGE TypeFamilyDependencies #}
{# LANGUAGE AllowAmbiguousTypes #}
{# LANGUAGE ConstraintKinds #}
main :: IO ()
main = return ()
type family F p = t  t > p
type IsF p t = (C p, t ~ F p)
class C p where
f :: (IsF p t) => t
f = undefined
g :: (IsF p t) => t
g = f
But if we define a "do nothing" type checker plugin like so:
{# OPTIONS_GHC dynamictoo #}
module MyPlugin (plugin) where
import Plugins (
Plugin(tcPlugin),
defaultPlugin, tcPlugin
)
import TcRnTypes (
TcPlugin(TcPlugin), tcPluginInit, tcPluginSolve, tcPluginStop,
TcPluginSolver,
TcPluginResult(TcPluginContradiction, TcPluginOk)
)
plugin :: Plugin
plugin = defaultPlugin { tcPlugin = const (Just myPlugin) }
myPlugin :: TcPlugin
myPlugin =
TcPlugin
{
tcPluginInit = return (),
tcPluginSolve = const solver,
tcPluginStop = const (return ())
}
solver :: TcPluginSolver
solver _ _ _ = return $ TcPluginOk [] []
And call it from our original source file by adding:
{# OPTIONS_GHC fplugin MyPlugin #}
We get the following error:
pluginbug.hs:18:5: error:
• Could not deduce (C p0, t ~ F p0) arising from a use of ‘f’
from the context: IsF p t
bound by the type signature for:
g :: IsF p t => t
at pluginbug.hs:17:119
The type variable ‘p0’ is ambiguous
Relevant bindings include g :: t (bound at pluginbug.hs:18:1)
• In the expression: f
In an equation for ‘g’: g = f
Note that not just calling my "do nothing" type checking plugin does this, to be sure, instead I called ghctypelitsnatnormalise
like so:
{# OPTIONS_GHC fplugin GHC.TypeLits.Normalise #}
And the same error results.
One solution is to remove (C p)
from the IsF
type declaration, and instead adding it to g
s definition, like so:
type IsF p t = (C p, t ~ F p)
type IsF p t = (t ~ F p)
g :: (IsF p t) => t
g :: (C p, IsF p t) => t
In addition, either of the following two solutions will get the code to compile:
IsF p t
in the class signature with t ~ F p
like so: f :: (IsF p t) => t
f :: (t ~ F p) => t
IsF p t
in the signature of g
as follows:g :: (IsF p t) => t
g :: (C p, t ~ F p) => t
Note that is we remove the class C
entirely (making f
an ordinary function) the bug disappears, but if instead replace the class with a constraint C
like so:
type family C t :: Constraint
the bug still appears.
So it seems this bug needs four things to all occur for it to appear:
Note that the error requires a type checking plugin to be called, if one does not override defaultPlugin
like so:
plugin = defaultPlugin { tcPlugin = const (Just myPlugin) }
and instead just does:
plugin = defaultPlugin
then the issue will not occur.
So in summary, it seems that calling a type checking plugin somehow affects ordinary type checking in particular circumstances. I don't think this should happen.
Modified example code again. A recursive definition is not required for the bug to occur, and the order of arguments matters.