#8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by simonpj): Thanks that's helpful. I can now at least compile it. One complicating factor is that you have a `Num` instance for `FastCyc`. You could simplify the setup by calling `plusFastCyc` in `cyclotomicTimeTest`, and defining {{{ plusFastCyc :: Num (t r) => FastCyc t r -> FastCyc t r -> FastCyc t r plusFastCyc (PowBasis v1) (PowBasis v2) = PowBasis $ v1 + v2 plusFastCyc p1@(DecBasis _) p2@(PowBasis _) = (g p1) + p2 plusFastCyc p1@(PowBasis _) p2@(DecBasis _) = p1 + (g p2) plusFastCyc p1 p2 = (g p1) + (g p2) }}} Now you can write your specilise pragmas (or not) for that. Do you get the same behaviour? That would elminate one source of complexity. Can you say in more detail what you ''expect'' to happen? The slow version (could we call it `slow` rather than `cyclotomicTimeTest`?) iterates `plusFastCyc` which necessariliy does a lot more work unpacking and packing those `PowBasis` constructors. Are you ok with that? But you aren't ok with ''something''. In short, it's a bit complicated for me to understand the problem. Maybe you can show some `-ddump-simpl` core and say "this call here should be specialsed, why doesn't the rule fire? Incidentally, if you want GHC to auto-specialise an '''imported''' function, to types that may not even be in scope in the defining module, you should mark that function as `INLINABLE` -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler