[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 oerjan):

 Replying to [[ticket:10598#comment:47|RyanGlScott]]:
 > I don't follow. Why should it be in the "never" category? As noted
 above, there are scenarios when GHC will derive `Enum` for newtypes, and
 they are perfectly captured in 2(b).

 Oh, I'd missed that. I guess removing the question mark was fine, then.

 However, that means `Enum` alone ''doesn't'' fit properly into my intended
 table scheme, since it's sort of a hybrid between lower left and middle
 right (actually, ''upper'' right, since there's no check needed on the
 shape of the newtype). Which means the current table indeed only describes
 when to do GND.

 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.

 >
 > > * Even though it's explained below, I have a hunch the phrase "bespoke
 typeclass instance" could be misinterpreted as referring to the selected
 strategy. It's a little longer, but "instance for a bespoke typeclass"
 feels less ambiguous.
 >
 > This is why I hate choosing syntax :)
 >
 > I'm going strictly by the dictionary definition of "bespoke" here, which
 means "tailor-made" or "custom-fit". That means the phrase "bespoke
 typeclass" doesn't make sense, since "bespoke" is a property of the
 instance, not the typeclass.

 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.

 > I've reworded it to make it a little clearer, hopefully.

 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.

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