#12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): To look at this from another perspective, if you write a function using methods from `Num` at a known type then GHC will specialise this code to the specific (+) defined for `Int`. If there is no instance then the definition will fail to type check. {{{#!hs foo :: Int -> Int -> Int foo = (+) }}} another valid choice would be to infer a constraint as there could be an instance for `Num` defined in another module which could then use this function. {{{#!hs foo1 :: Num Int => Int -> Int -> Int foo1 = (+) }}} This seems analogous to the worry that "it might not be long before someone complains that GHC is bypassing the dictionary they have passed in.". We already assume coherence so using it again here seems more consistent and will produce much better code! Secondly, these super classes exist mainly for convenience so that users do not have to type out many constraints. It currently seems that in order to write code which will definitely specialise then you have to write out each constraint individually and avoid using super classes. Constraint kinds are also not an option as you end up with exactly the same problem. It seems a shame that there are no free methods for abstracting a bunch of different constraints and still getting guarantees about performance. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12791#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler