[GHC] #12457: Deriving should be (more closely) integrated with other metaprogramming methods

[GHC]

#12457: Deriving should be (more closely) integrated with other metaprogramming
methods
-------------------------------------+-------------------------------------
           Reporter:  mpickering     |             Owner:
               Type:  feature        |            Status:  new
  request                            |
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  8.0.1
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 It is unfortunate that if we want to (efficiently) derive a new type class
 then we have to bake the derivation logic into GHC itself. It seems
 desirable to be able to implement new deriving methods in libraries in
 some manner.

 Ryan Scott says:

 > I think this would be a wonderful thing to have. Matthew Pickering
 > (cc'd) has expressed a desire to have all the logic for the `bespoke`
 > deriving strategies compartmentalized into a library that could easily
 > be expanded on in the future to support more typeclasses in base.
 > (Bifunctor, anyone?)
 >
 > Unfortunately, each of the major players in today's Haskell
 > metaprogramming scene that I'm aware of have some downfalls that make
 > them unsuitable as `deriving` replacements:
 >
 > * Template Haskell: Not portable. Staging issues make it hard to use as
 a drop-in replacement for the `deriving` keyword
 > * GHC generics: Can't express all the optimizations that the bespoke
 `deriving` algorithms perform. Unperformant.
 > * Haskell preprocessors: Difficult to integrate in a typical GHC
 workflow. Probably wouldn't have all the metadata you'd need to be
 feature-complete with what `deriving` does today.
 >
 > The way I see it, the whole `deriving` business as it currently stands
 > today is a somewhat-grotesque-but-darn-useful hack that gets around
 > the lack of a truly nice metaprogramming facility in Haskell. I'm
 > holding out hope that the work in
 > https://github.com/shayan-najd/NativeMetaprogramming makes things
 > nicer soon, and then we can revisit this idea. Until then,
 > -XDerivingStrategies provides a way to contain some of the madness of
 > `deriving` after having many features tacked onto it in recent GHC
 > releases.

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