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

[GHC]

#12791: Superclass methods could be more aggressively specialised.
-------------------------------------+-------------------------------------
        Reporter:  mpickering        |                Owner:  danharaj
            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):  Phab:D2714
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by danharaj):

 Replying to [comment:20 simonpj]:
 > That is an admirably clear explanation, thank you.  Could you please add
 it (suitably edited) as a `Note` in the code?
 >
 > I think I buy the idea in principle.  But do we have "in the wild"
 example(s) of where it makes a perceptible difference?  Will anyone
 notice/care?
 >
 > I don't think the implementation is right, I'm afraid, but I'll comment
 on Phab.
 >
 > Simon

 I've got a working draft of a patch that follows your guidance and
 includes my explanation as a note. I will polish it and put it on Phab
 once I have a convincing case that real code benefits from this change.
 Unfortunately, the code I'm trying to improve for the `reflex` package has
 an instance of this form that I would like to use in lieu of given
 superclasses:

 {{{#!hs
 instance t ~ SpiderTimeline Global => Reflex t where
   ...
 }}}

 This is a strange instance. Normally the `reflex` package is completely
 polymorphic in `t`. However there are performance issues with this
 approach if intermediate definitions are not inlined aggressively enough
 to end up at a call site where all the types are concrete (usually in
 `main = ...`). An experimental flag provides this instance in an attempt
 to get better code when user's write code whose constraints imply `Reflex
 t`.

 The classes that cause suboptimal code all have a similar form to this
 class declaration:

 {{{#!hs
 class (Monad m, Reflex t, DomSpace (DomBuilderSpace m), MonadAdjust t m)
    => DomBuilder t m | m -> t where
   ...
 }}}

 The code users of `reflex` tend to write looks like:

 {{{#!hs
 buildSomeDom :: DomBuilder t m => ... -> m ()
 }}}

 I don't know if there's anything reasonable we can do for this case, even
 with the strange instance. Nevertheless it's useful to me to have some
 real world code to work with.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12791#comment:22>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler