March 2014 - ghc-tickets

[GHC] #8898: Overall improvement for randomIvalInteger
by GHC 28 Mar '14

28 Mar '14

#8898: Overall improvement for randomIvalInteger -------------------------------------+------------------------------------- Reporter: novadenizen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect result Difficulty: Easy (less than 1 | at runtime hour) | Test Case: Blocked By: | Blocking: Related Tickets: 5278 5280 1120 | -------------------------------------+------------------------------------- The current randomIvalInteger implementation uses repeated div operations to approximate the size of the desired random output, then generates that number of random values from the given RandomGen. It does not compensate for the "mod base" uniformity problem. It also assumes that all RandomGen implementations produce the same range of random values as StdGen. My new implementation addresses all these correctness issues, with potentially a slight performance improvement. Instead of performing repeated div base operations to determine the size of the desired range, this uses faster (* base) operations. An equivalent set of intermediate Integers is generated still. To compensate for the "`mod` base" uniformity problem, the desired range size is multiplied by the q factor (1000 in my code). When k is the desired range and b^(n) is the range of numbers generated, and d = b^(n) div k, some elements will have probability d/b^(n) and others will have probability (d+1)/b^(n), resulting in significant nonuniformity when d is very small. When you extend the generated range beyond the minimum by a factor of q, you are guaranteeed that d will be at least q, so the nonuniformity will be much less consequential. This implementation also works with any RandomGen, even ones that produce as little as a single bit of entropy per next call or have a minimum bound other than zero. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8898> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8934: Advice To Help You Lose Weight ORIGINAL GARCINIA CAMBOGIA
by GHC 28 Mar '14

28 Mar '14

#8934: Advice To Help You Lose Weight ORIGINAL GARCINIA CAMBOGIA ------------------------------------+------------------------------------- Reporter: governer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | 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: | ------------------------------------+------------------------------------- As slim and skinny became the opening faith during this reproduction, unit reduction product has gained rank quality. The marketplace has been booming of these sorts of product. To exact some, these conservative valuate tea, slimming irregular, slimming pills, slimming belts, butterflies and lots of others. It is proliferated to a large difference that it is usually troublesome to request unconnected that among the different angulate measures rattling hearty and impressive. A word on a come of the fluid same tea and pills are tackled on this book to assistance yo [http://originalgarciniacambogiaresults.com/ ORIGINAL GARCINIA CAMBOGIA] u opt for that to use. Turn 24 Pro There conservative express numerous articles that assure tea as a acceptable slimming broker. Fit, there\'s any emancipationist to that still tea solitary cannot fulfil. Erst you eat in repast or alimentation second a day, you\'ll be fit to really retrogress cardinal to eighty calories on a daily cornerstone. This can be done thanks to the method of thermogenesis, a method of hotness production in organisms equivalent humans. With this, your metabolism can amount siamese to still exertion module increase our metastasis. With inflated metabolism, you\'ll be willing to contract the content that you rightful decrease a quicker peak of a discount of phoebe century to one grand calories on a daily foundation so as to advise that one to 2 blow weight exit. Tea cannot full vibration that. If that is the person then you bed got to eat the peak days as tercet month on a daily part. Thence, tea gift solely use as an Link in Nursing help. Fasting and workout conservativist amount plant more unimaginative than but uptake small 24 pro. Slimm 24 Pro Working Slimm 24 Pro fluid guarantees to mend out its personalty in a real victimize assets of your dimension. Siamese to the different consume, slimming powder should be punctually formal by a pupil. They're honest value reasons behindhand this. For one, slimming set number step ideally formal if and as extended as diet and apply tract instrument well-tried to be useless. Other instance, pills entails risks and complications. Connatural to the separate chemical devoured value accountable when making a selection what to gazump up and what ought to be excreted within the embody. Since these tablets or capsules aren\'t just confiscate on one part solely object for a become of your term (sometimes modify dual doses a day), it carries the danger of morbidity. Formerly our embody is overfull of toxins, it damages our great meat specially the liver and kidneys. These 2 parcel assess unexpendable that is why we change to tell superior reparation of them. http://originalgarciniacambogiaresults.com/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8934> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7644: Hackage docs for base library contain broken links
by GHC 28 Mar '14

28 Mar '14

#7644: Hackage docs for base library contain broken links -------------------------------------+------------------------------------ Reporter: JulesBean | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * owner: => hvr Comment: I'll pay attention to this when generating & uploading the docs to Hackage for [hackage:base] et al. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7644#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6056: INLINABLE pragma prevents worker-wrapper to happen.
by GHC 27 Mar '14

27 Mar '14

#6056: INLINABLE pragma prevents worker-wrapper to happen. --------------------------------------------+------------------------------ Reporter: milan | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by carter): I tested this just now on current HEAD (well, built 2 weeks ago) here are the three versions {{{ module Test where smallerAndRest :: Ord a => a -> [a] -> (Maybe a, [a]) smallerAndRest x [] = (Nothing, []) smallerAndRest x (y:ys) | y < x = (Just y, ys) | otherwise = smallerAndRest x ys {-# INLINABLE smallerAndRest #-} smallerAndRestGood :: Ord a => a -> [a] -> (Maybe a, [a]) smallerAndRestGood x ys = go x ys where go x [] = (Nothing, []) go x (y:ys) | y < x = (Just y, ys) | otherwise = go x ys {-# INLINABLE smallerAndRestGood #-} smallerAndRestGoodNotInlined :: Ord a => a -> [a] -> (Maybe a, [a]) smallerAndRestGoodNotInlined x ys = go x ys where go x [] = (Nothing, []) go x (y:ys) | y < x = (Just y, ys) | otherwise = go x ys }}} i used {{{ ghc -O1 -ddump-prep test.hs -fforce-recomp }}} with the following results {{{ ==================== CorePrep ==================== Result size of CorePrep = {terms: 123, types: 192, coercions: 0} lvl_r10X :: forall a_aTr. (Data.Maybe.Maybe a_aTr, [a_aTr]) [GblId, Caf=NoCafRefs, Str=DmdType m, Unf=OtherCon []] lvl_r10X = \ (@ a_aTr) -> (Data.Maybe.Nothing @ a_aTr, GHC.Types.[] @ a_aTr) Rec { Test.smallerAndRest [InlPrag=INLINABLE[ALWAYS], Occ=LoopBreaker] :: forall a_aDK. GHC.Classes.Ord a_aDK => a_aDK -> [a_aDK] -> (Data.Maybe.Maybe a_aDK, [a_aDK]) [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType <L,U(A,A,C(C1(U)),A,A,A,A,A)><L,U><S,1*U>m, Unf=OtherCon []] Test.smallerAndRest = \ (@ a_aTr) ($dOrd_s17b :: GHC.Classes.Ord a_aTr) (x_s17c :: a_aTr) (ds_s17d [Occ=Once!] :: [a_aTr]) -> case ds_s17d of _ [Occ=Dead] { [] -> lvl_r10X @ a_aTr; : y_s17f ys_s17g [Occ=Once*] -> case GHC.Classes.< @ a_aTr $dOrd_s17b y_s17f x_s17c of _ [Occ=Dead] { GHC.Types.False -> Test.smallerAndRest @ a_aTr $dOrd_s17b x_s17c ys_s17g; GHC.Types.True -> let { sat_s17i [Occ=Once] :: Data.Maybe.Maybe a_aTr [LclId, Str=DmdType] sat_s17i = Data.Maybe.Just @ a_aTr y_s17f } in (sat_s17i, ys_s17g) } } end Rec } Test.smallerAndRestGood [InlPrag=INLINABLE[ALWAYS]] :: forall a_aDJ. GHC.Classes.Ord a_aDJ => a_aDJ -> [a_aDJ] -> (Data.Maybe.Maybe a_aDJ, [a_aDJ]) [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType <L,U(A,A,C(C1(U)),A,A,A,A,A)><L,U><S,1*U>m, Unf=OtherCon []] Test.smallerAndRestGood = \ (@ a_aTb) ($dOrd_s17j :: GHC.Classes.Ord a_aTb) (x_s17k [Occ=Once] :: a_aTb) (ys_s17l [Occ=Once] :: [a_aTb]) -> let { lvl1_s17m [Occ=OnceL!] :: a_aTb -> a_aTb -> GHC.Types.Bool [LclId, Str=DmdType] lvl1_s17m = GHC.Classes.< @ a_aTb $dOrd_s17j } in letrec { $wgo_s17n [Occ=LoopBreaker] :: a_aTb -> [a_aTb] -> (# Data.Maybe.Maybe a_aTb, [a_aTb] #) [LclId, Arity=2, Str=DmdType <L,U><S,1*U>, Unf=OtherCon []] $wgo_s17n = \ (w_s17o :: a_aTb) (w1_s17p [Occ=Once!] :: [a_aTb]) -> case w1_s17p of _ [Occ=Dead] { [] -> (# Data.Maybe.Nothing @ a_aTb, GHC.Types.[] @ a_aTb #); : y_s17r ys1_s17s [Occ=Once*] -> case lvl1_s17m y_s17r w_s17o of _ [Occ=Dead] { GHC.Types.False -> $wgo_s17n w_s17o ys1_s17s; GHC.Types.True -> let { sat_s17u [Occ=Once] :: Data.Maybe.Maybe a_aTb [LclId, Str=DmdType] sat_s17u = Data.Maybe.Just @ a_aTb y_s17r } in (# sat_s17u, ys1_s17s #) } }; } in case $wgo_s17n x_s17k ys_s17l of _ [Occ=Dead] { (# ww1_s17w [Occ=Once], ww2_s17x [Occ=Once] #) -> (ww1_s17w, ww2_s17x) } Test.$wsmallerAndRestGoodNotInlined :: forall a_aql. GHC.Classes.Ord a_aql => a_aql -> [a_aql] -> (# Data.Maybe.Maybe a_aql, [a_aql] #) [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType <L,U(A,A,C(C1(U)),A,A,A,A,A)><L,U><S,1*U>, Unf=OtherCon []] Test.$wsmallerAndRestGoodNotInlined = \ (@ a_aql) (w_s17y :: GHC.Classes.Ord a_aql) (w1_s17z [Occ=Once] :: a_aql) (w2_s17A [Occ=Once] :: [a_aql]) -> let { lvl1_s17B [Occ=OnceL!] :: a_aql -> a_aql -> GHC.Types.Bool [LclId, Str=DmdType] lvl1_s17B = GHC.Classes.< @ a_aql w_s17y } in letrec { $wgo_s17C [Occ=LoopBreaker] :: a_aql -> [a_aql] -> (# Data.Maybe.Maybe a_aql, [a_aql] #) [LclId, Arity=2, Str=DmdType <L,U><S,1*U>, Unf=OtherCon []] $wgo_s17C = \ (w3_s17D :: a_aql) (w4_s17E [Occ=Once!] :: [a_aql]) -> case w4_s17E of _ [Occ=Dead] { [] -> (# Data.Maybe.Nothing @ a_aql, GHC.Types.[] @ a_aql #); : y_s17G ys_s17H [Occ=Once*] -> case lvl1_s17B y_s17G w3_s17D of _ [Occ=Dead] { GHC.Types.False -> $wgo_s17C w3_s17D ys_s17H; GHC.Types.True -> let { sat_s17J [Occ=Once] :: Data.Maybe.Maybe a_aql [LclId, Str=DmdType] sat_s17J = Data.Maybe.Just @ a_aql y_s17G } in (# sat_s17J, ys_s17H #) } }; } in $wgo_s17C w1_s17z w2_s17A Test.smallerAndRestGoodNotInlined [InlPrag=INLINE[0]] :: forall a_aql. GHC.Classes.Ord a_aql => a_aql -> [a_aql] -> (Data.Maybe.Maybe a_aql, [a_aql]) [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType <L,U(A,A,C(C1(U)),A,A,A,A,A)><L,U><S,1*U>m, Unf=OtherCon []] Test.smallerAndRestGoodNotInlined = \ (@ a_aql) (w_s17K [Occ=Once] :: GHC.Classes.Ord a_aql) (w1_s17L [Occ=Once] :: a_aql) (w2_s17M [Occ=Once] :: [a_aql]) -> case Test.$wsmallerAndRestGoodNotInlined @ a_aql w_s17K w1_s17L w2_s17M of _ [Occ=Dead] { (# ww1_s17O [Occ=Once], ww2_s17P [Occ=Once] #) -> (ww1_s17O, ww2_s17P) } }}} this seems to hint that doing worker wrapper by hand works, whether or not you marked it INLINEABLE. (i don't know enough about this topic to judge if that means its resolved or still a problem mind you) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6056#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6017: Reading ./.ghci files raises security issues
by GHC 27 Mar '14

27 Mar '14

#6017: Reading ./.ghci files raises security issues -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Marlow <marlowsd@…>): In [changeset:"a6f2c852d49313fa8acea2deb3741ab86c6ef995/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a6f2c852d49313fa8acea2deb3741ab86c6ef995" Don't perform permission checks for scripts named with -ghci-script (#6017) The user explicitly requested this script on the command-line, so it's unnecessary to require that the script is also owned by the user. Also, it is currently impossible to make a GHCi wrapper that invokes a custom script without first making a copy of the script to circumvent the permissions check, which seems wrong. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6017#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #989: Windows "native" port
by GHC 27 Mar '14

27 Mar '14

#989: Windows "native" port ---------------------------------+---------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Difficult (2-5 days) Test Case: N/A | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------------- Comment (by schyler): Just thought I would make a note that this is kind of blocking visual studio support. It's not easy to make a uniform visual studio extension for Haskell right now because it would be expected that it's able to link with other files in the same solution (.c, .cpp etc) however that's not the case since GHC uses gcc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/989#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8930: GHC API: List of available Pragmas
by GHC 27 Mar '14

27 Mar '14

#8930: GHC API: List of available Pragmas ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | 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: | ------------------------------------+------------------------------------- From https://github.com/kazu-yamamoto/ghc- mod/issues/103#issuecomment-14827257: It would be useful if the GHC API allowed us to query a list of supported pragmas. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8930> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8900: unordered-containers 19% slower in HEAD vs 7.6.3
by GHC 25 Mar '14

25 Mar '14

#8900: unordered-containers 19% slower in HEAD vs 7.6.3 ------------------------------+-------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Runtime performance bug (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I ran a simple benchmark that exercises `Data.HashMap.Lazy.insert`. It's 19% slower using HEAD compared to using 7.6.3. The generated Core is the same, but the new codegen generates substantially different Cmm. '''Steps to reproduce''' 1. Download the attached `HashMapInsert.hs` benchmark. 2. Install unordered-containers with both 7.6.3 and HEAD: {{{ $ cabal install -w ghc-7.6.3 unordered-containers-0.2.3.3 $ cabal install -w inplace/bin/ghc-stage2 unordered-containers-0.2.3.3 }}} 3. Compile the benchmark with both compilers: {{{ $ ghc-7.6.3 -O2 HashMapInsert.hs $ mv HashMapInsert HashMapInsertOld $ inplace/bin/ghc-stage2 -O2 HashMapInsert.hs $ mv HashMapInsert HashMapInsertNew }}} '''Results (best of 3 runs)''' 7.6.3 {{{ $ ./HashMapInsertOld +RTS -s 1,191,223,528 bytes allocated in the heap 141,978,520 bytes copied during GC 37,811,840 bytes maximum residency (8 sample(s)) 22,378,432 bytes maximum slop 99 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2277 colls, 0 par 0.06s 0.06s 0.0000s 0.0002s Gen 1 8 colls, 0 par 0.07s 0.10s 0.0127s 0.0479s INIT time 0.00s ( 0.00s elapsed) MUT time 0.24s ( 0.24s elapsed) GC time 0.13s ( 0.17s elapsed) EXIT time 0.00s ( 0.01s elapsed) Total time 0.37s ( 0.41s elapsed) %GC time 34.8% (40.3% elapsed) Alloc rate 4,923,204,681 bytes per MUT second Productivity 65.2% of total user, 59.0% of total elapsed }}} HEAD: {{{ $ ./HashMapInsertNew +RTS -s 1,191,223,128 bytes allocated in the heap 231,158,688 bytes copied during GC 55,533,064 bytes maximum residency (13 sample(s)) 22,378,488 bytes maximum slop 144 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2268 colls, 0 par 0.06s 0.07s 0.0000s 0.0003s Gen 1 13 colls, 0 par 0.12s 0.16s 0.0127s 0.0468s INIT time 0.00s ( 0.00s elapsed) MUT time 0.25s ( 0.25s elapsed) GC time 0.18s ( 0.23s elapsed) EXIT time 0.00s ( 0.01s elapsed) Total time 0.43s ( 0.49s elapsed) %GC time 41.6% (47.5% elapsed) Alloc rate 4,738,791,249 bytes per MUT second Productivity 58.3% of total user, 51.9% of total elapsed }}} (Note that this is without the patches in #8885, so they're not the cause.) An interesting difference is that we spend more time in GC in HEAD. I don't know if that's related. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8900> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

Re: [GHC] #3693: Show stack traces
by GHC 24 Mar '14

24 Mar '14

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Concerning the patch, I just looked at the `CoreSyn` changes in https://github.com/scpmw/ghc/commit/d829a088a98b1d716ad4d51593d22deae0e97d0a. I think it's a real improvement. I've left a couple of notes about `Ord` instances, which I hate. I still find the language that specifies what "placement" or "scoping" is, hard to understand. I'd urge you to add a list of all the transformations you can think of, in a table, with their placement/scoping properties. Something like this: {{{ Transformation Before After Placement Scoping ---------------------------------------------------------------- tick t (\x.e) \x.tick t e PlaceNonLam n/a tick t (let x = e in b) let x = e in tick t b --- never -- tick t (let x = e in b) let x = tick t e in tick t b n/a Soft (tick t fun) arg tick t (fun arg) ...etc... ...etc... }}} That would bring focus to the general descriptions. There should pretty be a line of the table for each call that makes use of the properties to allow, or disallow, a transformation. Oh, maybe you need a column for "counts" which is (I believe) a third property of a tick that, with scoped/placement, says which transformations are valid. Maybe you want a third data type rather than a boolean, to highlight this fact? Some comments with `tickishScoped` would be useful. Why are HPC ticks `NoScope`? That sounds as though we can move code outside an HPC tick so it is no longer covered. Or something. As the the wiki page, there is stuff that you take for granted but which forms the big picture * The fact that semantically ticks never have significance. * What it means for a tick to "cover" some code. * The fact that (I think that) ticks have lexical scope, from the point of view of what it means to be "covered". * A little summary of the various kinds of ticks, their significance and a rough sketch of how they work. For example, your new `SourceNotes` turn into something attached to DWARF records which is somehow recovered by a debugger. It's hard to get from the `SourceNote` data constructor to all that relevant other stuff in the compiler. Of course you can put all this big-picture stuff in `CoreSyn` with the data type declarations, but it's getting big. Maybe you want a module for the `Tick` stuff that `CoreSyn` imports, where we can accumulate this overview material. Broadly speaking, though, it looks fine to me. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:69> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8913: either bug or confusing error message mixing PolyKinds and TypeFamilies
by GHC 24 Mar '14

24 Mar '14

#8913: either bug or confusing error message mixing PolyKinds and TypeFamilies -------------------------------------------+------------------------------- Reporter: ghorn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1-rc2 Keywords: PolyKinds, TypeFamilies | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- I found this when using GHC.Generics, but it has to do with TypeFamilies so here is a stand-alone example: {{{ {-# OPTIONS_GHC -Wall #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE PolyKinds #-} module Test where class GCat f where gcat :: f p -> Int cat :: (GCat (MyRep a), MyGeneric a) => a -> Int cat x = gcat (from x) class MyGeneric a where type MyRep a :: * -> * from :: a -> (MyRep a) p }}} This code gives the error message {{{ src/Dyno/Test.hs:12:9: Could not deduce (GCat (MyRep a)) arising from a use of ‘gcat’ from the context (GCat (MyRep a), MyGeneric a) bound by the type signature for cat :: (GCat (MyRep a), MyGeneric a) => a -> Int at src/Dyno/Test.hs:11:8-48 In the expression: gcat (from x) In an equation for ‘cat’: cat x = gcat (from x) Failed, modules loaded: none. }}} If this is not a bug then error message is pretty confusing because it's saying "Can't deduce (C a) from (C a)", where the message I'm used to is "Can't derive (C a) from (C a0)" or something that indicates the mismatch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8913> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7