[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:  new
        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):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by RyanGlScott):

 Replying to [comment:27 simonpj]:
 > An alternative would be to require an instance declaration for DAD, thus
 > {{{
 > instance C a => C (T a)
 > }}}
 > That's all that is required, provided `C` has suitable generic default
 methods and `T` is an instance of `Generic`.  And if DAC always used this
 route, there'd be less ambiguity in the `deriving` clause of a data type
 declaration.

 I would strongly object to this! Literally the whole reason why I want
 this feature in the first place is so I can combine
 `GeneralizedNewtypeDeriving` with `DeriveAnyClass` in the presence of
 `deriving` clauses (which very conveniently don't require providing
 context). And moreover, if type out an instance manually like that, it's
 no longer `DeriveAnyClass`, it's pure Haskell 98! So imposing this
 "requirement" for `DeriveAnyClass` is tantamount to completely losing its
 utility, in my opinion.

 > I think (but I am not sure) that we don't allow standalone deriving for
 DAC; thus
 > {{{
 > deriving instance C a => C (T a)
 > }}}
 > would not work for DAC.  Is that right?  It seems reasonable to disallow
 it, because it's one word longer than the ordinary instance declaration.
 And if it is disallowed, then builtin and GND are already treated
 differently to DAC.  So we'd get
 >  * GND/builtin: `deriving` clauses and `deriving instance` declarations
 >  * DAC: always a plain `instance` decl
 >
 > I know that's not backward compatible..

 We do currently allow `StandaloneDeriving` to be used with any deriving
 strategy in existence, including `DeriveAnyClass`. You're right that using
 `DeriveAnyClass` in this fashion is a tad redundant (you can just as well
 drop the `deriving` part and get the same thing), but I don't think
 there's any reason to explicitly disallow it—after all, that would be
 another breaking change, and it does seem a bit //ad hoc// to disallow one
 form of `deriving` here when it could easily work with the ideas proposed
 in this ticket.

 > On Ryan's synonym thing, like oerjan I'm uncomfortable with pressing
 synonyms into service like this.

 OK, that's two votes against that idea, so I'll stop pursuing it :) In
 that case, pragmas looks like the path forward. Do the following names
 sound reasonable for pragmas?

 * `{-# BUILTIN #-}`
 * `{-# GND #-}`
 * `{-# DAC #-}` (goldfire proposed `{-# ANY #-}` above, but I'd argue that
 is a bit too ambiguous)

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