[GHC] #12791: Superclass methods could be more aggressively specialised.

[GHC]

#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