[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:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:  deriving
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 RyanGlScott):

 I suppose it depends on what you mean by "solved" :)

 It's true that `DerivingVia` provides a much higher degree of
 configurability than other deriving strategies, but it falls short of some
 goals:

 * If one's goal is to have a equivalent of, say, `deriving Ord` that
 produces equally efficient code, then `DerivingVia` isn't up to the task.
 Ultimately, the closest you could get is by leveraging `GHC.Generics`
 under the hood, which isn't always going to produce as efficient of code
 as a non-generics–based `Ord` instance.
 * Speaking of which, combining `GHC.Generics` with `DerivingVia` will only
 get you so far. You wouldn't be able to use this approach to derive
 `Bifunctor`, for instance, since we only have the `Generic` and `Generic1`
 classes for handling classes of kinds `* -> Constraint` and `(k -> *) ->
 Constraint`, respectively.
 * Ultimately, `DerivingVia` still relies on compiler magic. The original
 ambition here was to make `deriving` syntactic sugar for a Template
 Haskell splice so that the code underlying `deriving` could be expressed
 as a normal TH program. (That way, folks could extend it quite naturally.)
 There's still a long ways to go before that is possible.

 I'm not sure if those are what you had in mind when opening this ticket,
 so if they're not, feel free to close this.

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