[GHC] #15310: Derive Generic1 instances for types of kind (k -> *) -> * that include applications of the parameter

[GHC]

#15310: Derive Generic1 instances for types of kind (k -> *) -> * that include
applications of the parameter
-------------------------------------+-------------------------------------
        Reporter:  cedricshock       |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  low               |            Milestone:
       Component:  Compiler (Type    |              Version:
  checker)                           |             Keywords:  DeriveGeneric
      Resolution:                    |  Generic1
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 have to admit that I'm not fond of this approach, as it feels terribly
 //ad hoc//.

 These new representation types "fix" the issue by wiring in two very
 particular ways that the last parameter can appear in a data type. But
 there are an infinite numbers of ways that the last parameter can appear
 in a data type. What about:

 * `newtype A a = MkA (Either a a)`
 * `newtype B f = MkB (WrappedMonad f (Maybe f))`
 * etc.


 For every representation type that you cook up to fix one particular use
 case, one can always come up with another example that can't be
 represented neatly with the existing machinery.

 In my view, this reflects a weakness of `Generic1` approach in general.
 Namely, that one has to go through incredible contortions to bend data
 types to a certain shape just to be able to have a derived instance.
 Moreover, the contortions that one must do become even wilder if you start
 thinking about what it would take to support hypothetical `Generic2`,
 `Generic3`, etc. classes.

 My inclination is to not pursue this line of thinking, and instead
 recommend that you try an alternative generic programming library that's
 better suited to what you're trying to accomplish. The paper
 [http://dreixel.net/research/pdf/gpmp_colour.pdf Generic Programming with
 Multiple Parameters], which is authored by the same person who originally
 developed `Generic1`, was written to address this concern. In the paper,
 the author demonstrates a variant of `Generic` that works for any number
 of parameters (thus subsuming `Generic1`, `Generic2`, `Generic3`, etc.),
 and allows occurrences of these parameters wherever one desires.

 Bottom line: while `Generic1` is unfortunately restricted in what it's
 capable of, its capabilities are also quite predictable. I'm inclined to
 favor a predictable and limited approach over an approach which covers
 slightly more data types but adds unwarranted complexity.

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