[GHC] #10598: DeriveAnyClass and GND don't work well together

[GHC]

#10598: DeriveAnyClass and GND don't work well together
-------------------------------------+-------------------------------------
        Reporter:  osa1              |                Owner:  RyanGlScott
            Type:  bug               |               Status:  patch
        Priority:  normal            |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  7.11
      Resolution:                    |             Keywords:  Generics
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D2280
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by RyanGlScott):

 Replying to [comment:48 oerjan]:
 > Possibly, it could fit in the middle ''left'' if the table is slightly
 relabeled, so that the rows tell what to do about GND and the columns tell
 about general use. Like so:
 >
 > ||||                    ||= No extension required              =||||=
 Requires language extension to use =||
 > ||= GND when possible  =|| 2(a) || `Eq`, `Ord`, `Ix`, `Bounded` ||||
 ||
 > ||= GND with extension =|| 2(b) || `Enum`                       || 2(b)
 || `Functor`, `Foldable` ||
 > ||= Never select GND   =|| 2(c) || `Read`, `Show`               || 2(c)
 || `Data`, `Generic`, `Generic1`, `Typeable`, `Traversable`, `Lift` ||
 >
 > Which reminds me, I think maybe the word "silly" in step 1 should be
 "impossible", since after all some very silly things ''are'' allowed, like
 using anyclass on a class that doesn't support it.

 Sounds good to me. Updated with both suggestions.

 > Right. (I have no prior relationship with that word myself.) Anyway my
 point is that at this point in the algorithm, you ''don't'' want to branch
 on the (not yet) selected instance, but only on the class. This means you
 might not want to use a syntax ("bespoke typeclass instance") that could
 imply that "bespoke" is a property of ''that'' instance.
 >
 > My quibbling mind says that "when it would otherwise derive a `bespoke`
 instance" should be something like "when it supports `bespoke` instances",
 otherwise there are still corner cases that aren't obviously caught, such
 as deriving `Foldable` for a newtype with GND, deriving `Enum` for a
 newtype, or even (when interpreted intuitively) deriving an instance for
 which bespoke is selected, but the derivation fails for some other reason.

 I think I can live with the phrase "when deriving a class which supports
 bespoke instances". I've updated the wiki to use it.

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