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

 On Phab:D2280, kosmikus said:
 > In principle: I think this is great and definitely needed so that we can
 more reliably use all the different deriving-mechanisms, so thanks a lot
 for trying to move this forward.
 >
 > But: I think this should not be done via pragmas. (I know I've suggested
 using pragmas in the past myself, but I've changed my opinon.) I'm not
 sure whether there is a clear guideline for what should be a pragma and
 what not, but to me, I think stuff affecting optimizations or performance
 are perfectly fine, stuff that can make a difference between a program
 compiling at all or not (OVERLAPPING, OVERLAPPABLE) are critical, and
 stuff that changes the semantics/result of a program (this change) is too
 much. I'd much rather see this implemented via actual language syntax. It
 would also hopefully make it easier to extend it with more flexibility in
 subsequent versions.

 (Copying here because this is a design issue, not an implementation one.)

 I agree fully with this, including the bit that I, too, have suggested
 pragmas but now change my stance. I think we should have a guiding
 principle about pragmas. I propose this:

 * A pragma should either:
   1. Behave precisely like options that could be passed in at the command
 line, OR
   2. Have no effect on the semantics (static or dynamic) of the program

 Ideally, actually, we'd just have (2), but `LANGUAGE` doesn't qualify for
 (2).

 To be clear, by "semantics (static or dynamic)", I mean typability and
 runtime behavior.

 Browsing through the current set of accepted pragmas
 ([https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#pragmas
 in the manual], if that's complete) all pragmas meet this guideline except
 these:
 * The `OVERLAPPING`/`OVERLAPS`/`OVERLAPPABLE`/`INCOHERENT` pragmas, as
 these affect static semantics.
 * `RULES`, as these can affect dynamic semantics.

 Indeed, I'd be in favor of phasing out these pragmas in favor of other
 syntax. One could argue that `RULES` should be a pragma, because they
 shouldn't, if written correctly, affect runtime behavior. I would disagree
 with that argument, I think, but perhaps I'd be in the minority opinion.

 I know this is a larger discussion than on just this ticket, but I thought
 I'd mention this here to gauge response. If others like this idea at all,
 I'll post a fresh ticket.

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