November 2016 - ghc-tickets

[GHC] #12373: Type error but types match
by GHC 27 Jul '17

27 Jul '17

#12373: Type error but types match -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (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: -------------------------------------+------------------------------------- {{{ > unboxedsums git:(prim_sums_rebase_5) x cat primop_bug.hs {-# LANGUAGE MagicHash, ScopedTypeVariables, UnboxedTuples #-} module Main where import GHC.MVar import GHC.Prim import GHC.Types main :: IO () main = IO (\rw -> newMVar# rw) >> return () > unboxedsums git:(prim_sums_rebase_5) x ghc-stage1 primop_bug.hs -ddump- stg -ddump-cmm -ddump-to-file -fforce-recomp -dumpdir primop_fails -O -fprint-explicit-kinds [1 of 1] Compiling Main ( primop_bug.hs, primop_bug.o ) primop_bug.hs:10:19: error: • Couldn't match a lifted type with an unlifted type Expected type: (# State# RealWorld, MVar# RealWorld a0 #) Actual type: (# State# RealWorld, MVar# RealWorld a0 #) • In the expression: newMVar# rw In the first argument of ‘IO’, namely ‘(\ rw -> newMVar# rw)’ In the first argument of ‘(>>)’, namely ‘IO (\ rw -> newMVar# rw)’ }}} Tried with HEAD, 8.0.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12373> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12801: Misleading error message when deriving Functor
by GHC 25 Jul '17

25 Jul '17

#12801: Misleading error message when deriving Functor -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling this trivial demo program: {{{ data Container = Container [Wibble Int] deriving (Eq, Show) data Wibble a = Wibble a | Wobble deriving (Eq, Functor, Show) }}} results in the error message: {{{ a.hs:6:13: error: • No instance for (Eq (Wibble Int)) arising from the first field of ‘Container’ (type ‘[Wibble Int]’) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Eq Container) a.hs:6:17: error: • No instance for (Show (Wibble Int)) arising from the first field of ‘Container’ (type ‘[Wibble Int]’) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Show Container) a.hs:12:17: error: • Can't make a derived instance of ‘Functor Wibble’: You need DeriveFunctor to derive an instance for this class • In the data declaration for ‘Wibble’ }}} The "No instance for (Eq|Show)" are rather misleading, because the *actual* error is that the `{-# LANGUAGE DeriveFunctor #-}` pragma is missing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12801> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10684: Error cascade when unrelated class derivation fails
by GHC 25 Jul '17

25 Jul '17

#10684: Error cascade when unrelated class derivation fails -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Pretty minor bug, but I thought I'd point it out: {{{ module A where import Data.Typeable data A = A deriving (Show, Typeable) data B = B A deriving (Show) }}} I get two errors when I expect one: {{{ A.hs:3:28: Can't make a derived instance of `Typeable A': You need -XDeriveDataTypeable to derive an instance for this class In the data declaration for `A' A.hs:4:24: No instance for (Show A) arising from the 'deriving' clause of a data type declaration Possible fix: add an instance declaration for (Show A) or use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Show B) }}} The failed Typeable derivation also causes the Show derivation to fail, which causes an error later in the file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10684> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10064: Add support for "foo"## literals to MagicHash
by GHC 24 Jul '17

24 Jul '17

#10064: Add support for "foo"## literals to MagicHash -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm working on a high-performance library for building up buffers of data. Appending ByteStrings works pretty well, but, for bytestring literals, it's faster to avoid the CAF (and it's associated tag check + indirect jump) entirely and append a zero-terminate MagicHash string literal via Addr#. Then I discovered that it's 30% faster if you can avoid the strlen with an explicit length. See this benchmark: https://github.com/chadaustin /buffer- builder/blob/ac662962d6d3c21f206ab8e8121323b9f18677fa/bench/Bench.hs#L42 That API is not very pleasant, of course. :) Thus, here is a feature request: It would be great if "foo"## produced (# Int#, Addr# #), where the Int# is the length of the buffer in bytes. The compiler could enforce that the literal only contains 8-bit values. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9453: The example for GHC Generics is kinda broken
by GHC 24 Jul '17

24 Jul '17

#9453: The example for GHC Generics is kinda broken -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- From http://www.reddit.com/r/haskell/comments/2douzn/problem_with_popular_ghcgen…: The popular GHC.Generics serialization example at http://www.haskell.org/ghc/docs/latest/html/users_guide/generic- programming.html#idp25226064 illustrates how to serialize a sum datatype (a :+: b), with a 0 bit representing a and a 1 bit representing b. However, consider a :+: b :+: c. If the compiler treats this as (a :+: b) :+: c, then a is 00, b is 01, c is 1. If it's a :+: (b :+: c), then a is 0, b is 10, c is 11. The compiler's decision, even though (as I understand it) consistent for any given compile, could differ later. The manual, at http://hackage.haskell.org/package/generic- deriving-1.6.3/docs/Generics-Deriving-Base.html#g:9 states not to depend on the ordering, which the example does. I think this is a valid concern, and the manual should be at least updated to discuss this problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9453> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11375: Type aliases twice as slow to compile as closed type families.
by GHC 22 Jul '17

22 Jul '17

#11375: Type aliases twice as slow to compile as closed type families. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: MacOS X Architecture: aarch64 | Type of failure: Compile-time | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello guys! This bug is awkard at last to me. So I notiiced today, that using type aliases in my code takes twice as long to copile than using closed type families with just single member. So to be most precise - when I replace the following line: {{{ type XQ1 m a = Targets (Match m a) }}} with {{{ type family XQ1 m a where XQ1 m a = Targets (Match m a) }}} the compilation time drops from 15s to 7s (this type alias is heavily used across the application). I think it could be somehow related to the famous #8095 bug, but I can of course be wrong here. Unfortunetally the codebase is pretty big and its not so easy to make a minimal example, but I'll try to work on it during the upcoming weekend (please notify me if that would not be necessary). And some statistics from `-dshow-passes`: When using type alias: {{{ *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 10,303, types: 66,949, coercions: 16,383,834} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 10,722, types: 75,391, coercions: 16,507,338} Result size of Simplifier iteration=2 = {terms: 10,550, types: 74,437, coercions: 16,504,770} Result size of Simplifier iteration=3 = {terms: 10,543, types: 74,347, coercions: 16,504,734} Result size of Simplifier = {terms: 10,543, types: 74,347, coercions: 16,504,630} *** Tidy Core: Result size of Tidy Core = {terms: 10,846, types: 75,522, coercions: 16,504,729} *** CorePrep: Result size of CorePrep = {terms: 14,823, types: 96,430, coercions: 16,504,729} *** ByteCodeGen: Upsweep completely successful. *** Deleting temp files: Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64965_0/ghc_95.c Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64965_0/ghc_94.o Ok, modules loaded: Prologue, Type.Bool, Type.Container, Type.List, Type.Set, Data.Cata, Type.Promotion, Data.Bits.Mask, Control.Monad.State.Dependent, Control.Monad.Poly, Control.Applicative.Poly, Type.Regex, Type.Either, Data.Reprx, Data.Impossible, Type.Cache.TH, Main, Control.Lens.Utils, Control.Lens.Wrapped.Utils, Data.Text.CodeBuilder, Data.Text.CodeBuilder.Tok, Data.Text.CodeBuilder.Builder, Data.Text.CodeBuilder.Doc, Data.Binary.Instances.Missing, Data.Default.Instances.Missing, Data.String.Class, Data.Text.Class, Data.Convert, Data.Layer, Data.Container.Class, Data.Container.List, Data.Functor.Utils, Type.Operators, Type.Show, Type.Wrapped, Data.Container.Opts, Data.Container.Poly, Data.Convert.Base, Data.Convert.Instances, Data.Convert.Instances.Map, Data.Convert.Instances.Num, Data.Convert.Instances.Text, Data.Convert.Instances.TH, Data.Convert.Bound, Data.Bits.Base. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: ... }}} and with type families: {{{ *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 310, types: 867, coercions: 78} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 301, types: 878, coercions: 296} Result size of Simplifier = {terms: 301, types: 878, coercions: 293} *** Tidy Core: Result size of Tidy Core = {terms: 337, types: 1,002, coercions: 293} *** CorePrep: Result size of CorePrep = {terms: 475, types: 1,305, coercions: 293} *** ByteCodeGen: *** Deleting temp files: Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_93.c Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_92.o compile: input file /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_1.hscpp *** Checking old interface for Main: [45 of 45] Compiling Main ( /Users/wdanilo/dev/hs/public/variants/Main.hs, interpreted ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 10,303, types: 67,609, coercions: 162,249} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 10,722, types: 75,721, coercions: 323,027} Result size of Simplifier iteration=2 = {terms: 10,550, types: 74,767, coercions: 320,473} Result size of Simplifier iteration=3 = {terms: 10,543, types: 74,677, coercions: 320,437} Result size of Simplifier = {terms: 10,543, types: 74,677, coercions: 320,333} *** Tidy Core: Result size of Tidy Core = {terms: 10,846, types: 75,852, coercions: 320,432} *** CorePrep: Result size of CorePrep = {terms: 14,823, types: 96,760, coercions: 320,432} *** ByteCodeGen: Upsweep completely successful. *** Deleting temp files: Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_95.c Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_94.o Ok, modules loaded: Prologue, Type.Bool, Type.Container, Type.List, Type.Set, Data.Cata, Type.Promotion, Data.Bits.Mask, Control.Monad.State.Dependent, Control.Monad.Poly, Control.Applicative.Poly, Type.Regex, Type.Either, Data.Reprx, Data.Impossible, Type.Cache.TH, Main, Control.Lens.Utils, Control.Lens.Wrapped.Utils, Data.Text.CodeBuilder, Data.Text.CodeBuilder.Tok, Data.Text.CodeBuilder.Builder, Data.Text.CodeBuilder.Doc, Data.Binary.Instances.Missing, Data.Default.Instances.Missing, Data.String.Class, Data.Text.Class, Data.Convert, Data.Layer, Data.Container.Class, Data.Container.List, Data.Functor.Utils, Type.Operators, Type.Show, Type.Wrapped, Data.Container.Opts, Data.Container.Poly, Data.Convert.Base, Data.Convert.Instances, Data.Convert.Instances.Map, Data.Convert.Instances.Num, Data.Convert.Instances.Text, Data.Convert.Instances.TH, Data.Convert.Bound, Data.Bits.Base. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: ... }}} As we can see the type aliases produce much more coertions: 16,383,834 vs 78 using type families. This is really interesting thing and it seems related to the linked bug above. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11375> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g)
by GHC 19 Jul '17

19 Jul '17

#11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- Tried to buld syb-0.6 testsuite with '-O0 -g' flags today and noticed compiler hung for a couple of hours. Distilled example from syb-0.6 testsuite (exact example attached): {{{#!hs {-# LANGUAGE NoImplicitPrelude #-} {-# OPTIONS_GHC -O0 #-} module Bug (bug) where {-# NOINLINE f #-} f :: a -> a f v = v bug :: [()] bug = f v v :: [()] v = [(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),() ,(),(),(),(),() ... --- a lot of these ] }}} {{{ $ time ghc -c -fforce-recomp -O0 Bug.hs real 0m0.333s user 0m0.288s sys 0m0.042s $ time ghc -c -fforce-recomp -O0 -g Bug.hs real 0m40.241s user 0m40.021s sys 0m0.070s }}} For some reason '''-g''' manages slow things down at a large factor. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11095> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #8903: Add dead store elimination
by GHC 18 Jul '17

18 Jul '17

#8903: Add dead store elimination ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- We could use some dead store elimination in the code generator. Here's some Cmm that has redundant stores to the same locations: {{{ // thawArray#: I64[Hp - 168] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info@GOTPCREL]; I64[Hp - 160] = 16; I64[Hp - 152] = 17; _c2nT::I64 = Hp - 168; call MO_Memcpy(_c2nT::I64 + 24, _s2cx::P64 + 24, 128, 8); // writeArray#: P64[(_c2nT::I64 + 24) + (_s2cy::I64 << 3)] = _s2cE::P64; I64[_c2nT::I64] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info@GOTPCREL]; I8[(_c2nT::I64 + 24) + ((I64[_c2nT::I64 + 8] << 3) + (_s2cy::I64 >> 7))] = 1 :: W8; // unsafeFreeze# I64[_c2nT::I64] = I64[PicBaseReg + stg_MUT_ARR_PTRS_FROZEN0_info@GOTPCREL]; }}} There are three stores to the same location (`I64[_c2nT::I64]`). (There's also one much less obvious double store to another location, which will probably be much harder to address: the store to `P64[(_c2nT::I64 + 24) + (_s2cy::I64 << 3)]` overwrites a word previous written by the `MO_Memcpy`. Getting to that one will be hard as the memcoy callish !MachOp only gets expanded in the backend.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8903> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9630: compile-time performance regression (probably due to Generics)
by GHC 18 Jul '17

18 Jul '17

#9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time performance bug Related Tickets: #9583 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This is a continuation of #9583 Compiling latest Cabal from Git's `Language.Haskell.Extension` module shows a significant performance regression with respect to GHC 7.8.3: {{{ $ uname -a Linux duo 3.17.0-031700rc6-generic #201409211935 SMP Sun Sep 21 23:37:11 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ git describe cabal-install_merged-1912-g7161e4c ######################################################################################## $ /opt/ghc/7.8.3/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 $ /opt/ghc/7.8.3/bin/ghc -Rghc-timing -O -c Language/Haskell/Extension.hs <<ghc: 5228751760 bytes, 543 GCs, 34135677/114940864 avg/max bytes residency (14 samples), 273M in use, 0.00 INIT (0.03 elapsed), 4.96 MUT (5.28 elapsed), 3.26 GC (3.47 elapsed) :ghc>> ######################################################################################## $ /opt/ghc/head/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 7.9.20140923 $ /opt/ghc/head/bin/ghc -Rghc-timing -O -c Language/Haskell/Extension.hs <<ghc: 125917854120 bytes, 3181 GCs, 349136895/833496072 avg/max bytes residency (30 samples), 2096M in use, 0.001 INIT (0.001 elapsed), 133.003 MUT (142.730 elapsed), 73.241 GC (78.234 elapsed) :ghc>> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9630> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 66

[GHC] #12131: Can't solve constraints with UndecidableSuperClasses but can infer kind (+ undesired order of kinds)
by GHC 18 Jul '17

18 Jul '17

#12131: Can't solve constraints with UndecidableSuperClasses but can infer kind (+ undesired order of kinds) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple UndecidableSuperClasses | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11480 #12025 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The Glorious Glasgow Haskell Compilation System, version 8.0.1. Code taken from [https://gist.github.com/ekmett/b26363fc0f38777a637d gist] with {{{#!hs fmap :: p a b -> q (f a) (f b) }}} replaced by {{{#!hs fmap :: Dom f a b -> Cod f (f a) (f b) }}} If you enable `DataKinds` and `TypeInType` `:kind` will happily tell you its kind: {{{ ghci> :kind 'Main.Nat 'Main.Nat :: forall j i (p :: Cat i) (q :: Cat j) (f :: i -> j) (g :: i -> j). (FunctorOf p q f, FunctorOf p q g) => (forall (a :: i). Ob p a => q (f a) (g a)) -> Main.Nat p q f g }}} but if you try `:type Nat` it spits out a long list of unsolved constraints {{{ ghci> :type Nat <interactive>:1:1: error: solveWanteds: too many iterations (limit = 1) Unsolved: WC {wc_simple = [W] $dFunctor_ag3Y :: Main.Functor f_ag3S (CDictCan) [W] $dFunctor_ag4d :: Main.Functor g_ag3T (CDictCan) [D] _ :: Main.Functor s_ag51 (CDictCan) [D] _ :: Main.Functor s_ag5a (CDictCan) [D] _ :: Main.Functor s_ag4W (CDictCan) [D] _ :: Main.Functor s_ag55 (CDictCan) [D] _ :: Category s_ag51 (CDictCan) [D] _ :: Category s_ag5a (CDictCan) [D] _ :: Category s_ag4W (CDictCan) [D] _ :: Category s_ag55 (CDictCan) [W] hole{ag4Y} :: Dom g_ag3T ~ Dom f_ag3S (CNonCanonical) [W] hole{ag53} :: Cod g_ag3T ~ Cod f_ag3S (CNonCanonical) [D] _ :: Dom (Dom f_ag3S) ~ Op (Dom f_ag3S) (CNonCanonical) [D] _ :: Cod (Dom f_ag3S) }}} This seems like #11480. This makes undecidable superclasses a harsh master and raises two questions that I'll bundle together: 1. Why can the `:kind` be inferred but not the `:type`? It works when given extra information: {{{ ghci> :type Nat @_ @_ @(->) @(->) Nat @_ @_ @(->) @(->) :: (Cod g ~ (->), Dom g ~ (->), Cod f ~ (->), Dom f ~ (->), Main.Functor g, Main.Functor f) => (forall a. Vacuous (->) a => f a -> g a) -> Main.Nat (->) (->) f g }}} {{{ ghci> :type Nat @_ @_ @_ @_ @[] @Maybe Nat @_ @_ @_ @_ @[] @Maybe :: (forall a. Vacuous (->) a => [a] -> Maybe a) -> Main.Nat (->) (->) [] Maybe }}} {{{ ghci> :type Nat @_ @_ @_ @_ @[] @Maybe listToMaybe Nat @_ @_ @_ @_ @[] @Maybe listToMaybe :: Main.Nat (->) (->) [] Maybe }}} 2. Why is `j` positioned before `i` (most likely because of `forall a. ...` but I tried tinkering without success? Is there any trick to ordering it as you'd expect `forall i j (p :: Cat i) (q :: Cat j)` or is it not possible per #12025? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7