[GHC] #11068: Make Generic/Generic1 methods inlinable

[GHC]

#11068: Make Generic/Generic1 methods inlinable
-------------------------------------+-------------------------------------
        Reporter:  glguy             |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.10.2
      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:D1447
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by glguy):

 Hi Simon,

 The problem I'm working on is indeed related to José's work. I'm solving
 the problem that GHC doesn't use Appliative and Functor laws to rewrite
 code using Haskell instead of rewrite rules. I "run" the code at a lifted
 version of the desired type `f` that uses the Applicative laws to rewrite
 a term to be left associated in the `<*>`s and using a single `<$>`.

 Using this technique allows me to derive efficient code that is generic in
 terms of Functor and Applicative on a case by case basis rather than with
 global rules.

 {{{
 badTraversal :: Traversal' (Int,Int,Int) Int
 badTraversal f (x,y,z) =
   pure (\x' (y',z') -> (x',y',z')) <*> f x <*> ((,) <$> f y <*> f z)

 goodTraversal :: Traversal' (Int,Int,Int) Int
 goodTraversal = boggling badTraversal
 -- generated core is roughly: \f (x,y,z) -> (,,) <$> f x <*> f y <*> f z
 }}}

 The code from `badTraversal` could have been easily generated using
 GHC.Generics, but the efficient version can be recovered using the
 `boggling` operation defined in repository mentioned above.

 As far as my request to add the inline pragma, I think I might have
 misunderstood what GHC was doing. My goal was to ensure that
 from/to/from1/to1 would be able to inline across module boundaries even
 when their definitions were large due to the type being large. However
 after revisiting my test case I was struggling to reproduce that the
 change fixed anything, so I closed the change request (but forgot to
 change this ticket)

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