March 2019 - ghc-tickets

[GHC] #9832: Get rid of PERL dependency of `ghc-split`
by GHC 08 Mar '19

08 Mar '19

#9832: Get rid of PERL dependency of `ghc-split` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- (writeme) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9832> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 37

[GHC] #8964: split_marker_entry assert breaks -split-objs and -ddump-opt-cmm
by GHC 08 Mar '19

08 Mar '19

#8964: split_marker_entry assert breaks -split-objs and -ddump-opt-cmm -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: lowest | Milestone: ⊥ Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Compile-time Difficulty: Easy (less than 1 | crash hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- ...since the pretty-printer attempts to force the blocks list of the split_marker_entry proc. I'm not really sure what the right way to fix this is: just provide an empty block list, or hack the pretty-printer to treat split markers specially. But should be easy to fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8964> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8685: -split-objs doesn't work for executables
by GHC 08 Mar '19

08 Mar '19

#8685: -split-objs doesn't work for executables ------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- While investigating [this bug report](https://github.com/haskell/cabal/issues/1611), I've noticed that the `-split-objs` option only works for libraries, but not for executables. That is, unlike in the case of libraries, the driver feeds only `A.o B.o ...` files to the linker instead of `A_split_0.o A_split_1.o ... B_split_0.o B_split_1.o ...`. It'd be nice if `-split-objs` could be changed to also work on executables. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8685> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8629: Option 'split-objs' being ignored when trying to reduce object code size in iOS cross-compilation
by GHC 08 Mar '19

08 Mar '19

#8629: Option 'split-objs' being ignored when trying to reduce object code size in iOS cross-compilation ------------------------------------+--------------------------------- Reporter: f1rstmistake | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: ios | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- I have been trying to statically link Pandoc packages to iOS application following the guide in https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS and it's great so far! I have finally successfully use Pandoc library in iOS app, but the binary size is very big! 1. More than 50MB when using Pandoc library. 2. Around 5MB for simple haskell code. I try to add “split-objs: True” in .cabal/config file, but when running cabal I got this message: {{{ Preprocessing library pandoc-1.12.2.1... unused terminals: 1 on the commandline: Warning: ignoring -fsplit-objs }}} And if I ignore that, at the end of build, I get another error message that stop the build. {{{ cabal: dist-i386/build/Text/Pandoc_o_split: does not exist }}} I try with another package and got similar error message. It seems that split-objs not only being ignored by cross-compilation ghc, but will also fail the build. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8629> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16408: incomplete ghc-8.6.4 windows binary tarball
by GHC 08 Mar '19

08 Mar '19

#16408: incomplete ghc-8.6.4 windows binary tarball -------------------------------------+------------------------------------- Reporter: ruomad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.6.4 (other) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- the tarball for windows binaries does not include profiling version for core libraries, which leads to this cryptic error "base must match >=4.7 && <5, but the stack configuration has no specified version (latest matching version is 4.12.0.0)" Also, haddock fails because there is no haddock.exe, only haddock-8.6.4.exe -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16408> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15913: ghc-8.6.2 fails to build on s390x (unregisterised): ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’?
by GHC 08 Mar '19

08 Mar '19

#15913: ghc-8.6.2 fails to build on s390x (unregisterised): ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (make) | Keywords: | Operating System: Linux Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc-8.6 fails to build on s390x (likely any unregisterised build with ghc 8.2 or 8.4) apparently due to some mix up of include files between stage0 and stage1 compilers. {{{ "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -package-db libraries/bootstrapping.conf -this-unit-id ghc-8.6.2 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/stage1/build -Icompiler/stage1/build -icompiler/stage1/build/./autogen -Icompiler/stage1/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -Icompiler/stage1/build/. -Icompiler/stage1/build/parser -Icompiler/stage1/build/utils -Icompiler/stage1/build/stage1 -optP- include -optPcompiler/stage1/build/./autogen/cabal_macros.h -package-id array-0.5.2.0 -package-id base-4.10.1.0 -package-id binary-0.8.6.0 -package-id bytestring-0.10.8.2 -package-id containers-0.5.10.2 -package- id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id filepath-1.4.1.2 -package-id ghc-boot-8.6.2 -package-id ghc-boot-th-8.6.2 -package-id ghc-heap-8.6.2 -package-id ghci-8.6.2 -package-id hpc-0.6.0.3 -package-id process-1.6.1.0 -package-id template-haskell-2.14.0.0 -package-id terminfo-0.4.1.2 -package-id time-1.8.0.2 -package-id transformers-0.5.5.0 -package-id unix-2.7.2.2 -Wall -Wno-name-shadowing -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -Wnoncanonical-monoid-instances -this-unit-id ghc -XHaskell2010 -XNoImplicitPrelude -DNO_REGS -DNOSMP -optc-DNOSMP -DSTAGE=1 -Rghc-timing -Wcpp-undef -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -c compiler/utils/Binary.hs -o compiler/stage1/build/Binary.o /tmp/ghc24ef_0/ghc_3.hc: In function ‘cNqW_entry’: /tmp/ghc24ef_0/ghc_3.hc:50988:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 50988 | ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc24ef_0/ghc_3.hc:50988:61: error: note: each undeclared identifier is reported only once for each function it appears in | 50988 | ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc24ef_0/ghc_3.hc: In function ‘cNra_entry’: /tmp/ghc24ef_0/ghc_3.hc:51045:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 51045 | ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc24ef_0/ghc_3.hc: In function ‘sHDG_entry’: /tmp/ghc24ef_0/ghc_3.hc:56499:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 56499 | ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc24ef_0/ghc_3.hc: In function ‘cO9A_entry’: /tmp/ghc24ef_0/ghc_3.hc:56819:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 56819 | ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc24ef_0/ghc_3.hc: In function ‘cOa5_entry’: /tmp/ghc24ef_0/ghc_3.hc:56907:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 56907 | ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) <<ghc: 5594223368 bytes, 548 GCs, 37786228/65761936 avg/max bytes residency (14 samples), 177M in use, 0.001 INIT (0.001 elapsed), 6.007 MUT (6.639 elapsed), 2.510 GC (2.514 elapsed) :ghc>> make[1]: *** [compiler/ghc.mk:446: compiler/stage1/build/Binary.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:125: all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15913> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4
by GHC 08 Mar '19

08 Mar '19

#16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.6.4 (other) | Keywords: array | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following: ```haskell import Data.Array.IArray import Data.Bits import Data.Word loop :: Array Int Word32 loop = accumArray (curry snd) 0 (0,79) $ [(i, xxor i) | i <- [16..79]] where xxor :: Int -> Word32 xxor i = loop ! (i-16) `xor` loop ! (i-3) `xor` loop ! (i-8) `xor` loop ! (i-14) ``` When loaded into ghci-8.4.4, `loop` works fine: ``` GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/unknown/.ghci λ> :l array.hs [1 of 1] Compiling Main ( array.hs, interpreted ) Ok, one module loaded. λ> loop array (0,79) [(0,0),(1,0),(2,0),(3,0),(4,0),(5,0),(6,0),(7,0),(8,0),(9,0),(10,0),(11,0),(12,0),(13,0),(14,0),(15,0),(16,0),(17,0),(18,0),(19,0),(20,0),(21,0),(22,0),(23,0),(24,0),(25,0),(26,0),(27,0),(28,0),(29,0),(30,0),(31,0),(32,0),(33,0),(34,0),(35,0),(36,0),(37,0),(38,0),(39,0),(40,0),(41,0),(42,0),(43,0),(44,0),(45,0),(46,0),(47,0),(48,0),(49,0),(50,0),(51,0),(52,0),(53,0),(54,0),(55,0),(56,0),(57,0),(58,0),(59,0),(60,0),(61,0),(62,0),(63,0),(64,0),(65,0),(66,0),(67,0),(68,0),(69,0),(70,0),(71,0),(72,0),(73,0),(74,0),(75,0),(76,0),(77,0),(78,0),(79,0)] ``` However, when loaded into ghci-8.6.4, it hangs (with no CPU utilization): ``` GHCi, version 8.6.4: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/unknown/.ghci λ> :l array.hs [1 of 1] Compiling Main ( array.hs, interpreted ) Ok, one module loaded. λ> loop array ``` The definition of loop is a piece of code taken from Crypto library (https://hackage.haskell.org/package/Crypto-4.2.5.1/docs/src/Data-Digest- SHA1.html, `oneBlock` function) Granted, this library is pretty much dead (last update in 2012), but it's a bit suspect that code suddenly stops working in the worst way possible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16406> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8095: TypeFamilies painfully slow
by GHC 08 Mar '19

08 Mar '19

#8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | -------------------------------------+------------------------------------- I'm using the TypeFamilies extension to generate types that are quite large. GHC can handle these large types fine when they are created manually, but when type families get involved, GHC's performance dies. Unlike in ticket #5321, using tail recursion does not eliminate the problem, and the order of arguments greatly affects compile time. I've attached a file Types.hs that demonstrates the problems. This file generates another Haskell file which has the problems. It takes 3 flags. The first is the size of the type to generate, the second is which type family function to use, and the third is whether to call the type family or just use a manually generated type. Here are my performance results: Using non-tail recursion, I get these results. I have to increase the stack size based on the size of the type I want to generate. {{{ $ ./Types 200 a a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=250 real 0m2.973s $ ./Types 300 a a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=350 real 0m6.018s $ ./Types 400 a a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=450 real 0m9.995s $ ./Types 500 a a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=550 real 0m15.645s }}} Tail recursion generates much slower compile times for some reason, and I still need to adjust the stack size: {{{ $ ./Types 200 b a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=250 real 0m16.120s }}} Changing the order of arguments to the recursive type family greatly changes the run times: {{{ $ ./Types 200 c a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=250 real 0m6.095s }}} Without the type family, I get MUCH better performance: {{{ $ ./Types 10000 a d > test.hs && time ghc test.hs > /dev/null real 0m2.271s }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8095> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 64

[GHC] #16365: Inconsistency in quantified constraint solving
by GHC 08 Mar '19

08 Mar '19

#16365: Inconsistency in quantified constraint solving -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Kind import Data.Proxy class C a where m :: a -> () data Dict c = c => Dict ----- type family F a :: Type -> Type class C (F a b) => CF a b instance C (F a b) => CF a b works1 :: (forall z. CF a z) => Proxy (a, b) -> Dict (CF a b) works1 _ = Dict works2 :: ( CF a b) => Proxy (a, b) -> Dict (C (F a b)) works2 _ = Dict works3, fails :: (forall z. CF a z) => Proxy (a, b) -> Dict (C (F a b)) works3 p | Dict <- works1 p = Dict fails _ = Dict }}} `fails`, as its name suggests, fails to typecheck: {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:33:11: error: • Could not deduce (C (F a b)) arising from a use of ‘Dict’ from the context: forall z. CF a z bound by the type signature for: fails :: forall a b. (forall z. CF a z) => Proxy (a, b) -> Dict (C (F a b)) at Bug.hs:31:1-71 • In the expression: Dict In an equation for ‘fails’: fails _ = Dict | 33 | fails _ = Dict | ^^^^ }}} But I see no reason why this shouldn't typecheck. After all, the fact that `works1` typechecks proves that GHC's constraint solver is perfectly capable of deducing that `(forall z. CF a z)` implies `(CF a b)`, and the fact that `works2` typechecks proves that GHC's constraint solver is perfectly capable of deducing that `(CF a b)` implies that `(C (F a b))`. Why then can GHC's constraint solver not connect the dots and deduce that `(forall z. CF a z)` implies `(C (F a b))` (in the type of `fails`)? Note that something with the type `(forall z. CF a z) => Proxy (a, b) -> Dict (C (F a b))` //can// be made to work if you explicitly guide GHC along with explicit pattern-matching on a `Dict`, as `works3` demonstrates. But I claim that this shouldn't be necessary. Moreover, in this variation of the program above: {{{#!hs -- <as above> ----- data G a :: Type -> Type class C (G a b) => CG a b instance C (G a b) => CG a b works1' :: (forall z. CG a z) => Proxy (a, b) -> Dict (CG a b) works1' _ = Dict works2' :: ( CG a b) => Proxy (a, b) -> Dict (C (G a b)) works2' _ = Dict works3' :: (forall z. CG a z) => Proxy (a, b) -> Dict (C (G a b)) works3' _ = Dict }}} `works3'` needs no explicit `Dict` pattern-matching to typecheck. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16365> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16374: Cannot deduce constraint from itself with poly-kinded type family
by GHC 08 Mar '19

08 Mar '19

#16374: Cannot deduce constraint from itself with poly-kinded type family -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling {{{#!hs {-# LANGUAGE PolyKinds, TypeFamilies #-} module Eq where type family F a :: k where withEq :: F Int ~ F Bool => a withEq = undefined }}} gives an arguably confusing error message: {{{ Eq.hs:7:11: error: • Could not deduce: F Int ~ F Bool from the context: F Int ~ F Bool bound by the type signature for: withEq :: forall k a. (F Int ~ F Bool) => a at Eq.hs:7:11-29 NB: ‘F’ is a non-injective type family The type variable ‘k0’ is ambiguous • In the ambiguity check for ‘withEq’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: withEq :: F Int ~ F Bool => a }}} I'm not claiming this program should necessarily typecheck, but "Cannot deduce X from the context X" induces head-scratching. Replacing `k` with `*` in the definition of `F` makes the error go away. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16374> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2