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

 I don't really care what color we paint the bikeshed with, but I will
 caution that we're dealing with a perilous part of the parser here, and
 that cramming more syntax into `deriving` clauses might lead to more
 trouble than it's worth.

 The parser rule for `deriving` clauses is currently
 [http://git.haskell.org/ghc.git/blob/1e6701011425edb3553abc17c094a2a9faee4fd5:/compiler/parser/Parser.y#l1729
 this]:

 {{{
 deriv_types :: { [LHsSigType RdrName] }
         : typedoc                       { [mkLHsSigType $1] }

         | typedoc ',' deriv_types       {% addAnnotation (gl $1) AnnComma
 (gl $2)
                                            >> return (mkLHsSigType $1 :
 $3) }
 }}}

 In other words, arbitrary types. This poses a problem for trying to
 introduce new syntax in front of a derived type, since:

 1. Uppercase identifiers can be confused for type constructors
 2. Lowercase identifiers can be confused for type variables

 To my knowledge, no one has proposed any alternatives to the suggested
 designs above, but if you do have a suggestion, please details how you
 would resolve this ambiguity. The pragma approach, while perhaps
 stretching the powers that most pragmas have, do not introduce any
 ambiguities into the parser.

 Also, I'm not sure why one pragmas wouldn't be amenable to "extend it with
 more flexibility in subsequent versions". In fact, that's precisely one of
 the reasons why I like pragmas, since it's cheap to add more of them in
 the future, and they're wildly configurable. In fact, later I hope to
 explore extending the GHC plugin mechanism to allow programmers to write
 their own deriving mechanisms, with something like:

 {{{#!hs
 data Foo = Foo Bar Baz deriving {-# CUSTOM myDeriv #-} C

 myDeriv :: SrcSpan -> TyCon -> TcM (LHsBinds RdrName, BagDerivStuff)
 myDeriv = ...
 }}}

 It would be dead simple to add this functionality via a pragma. With
 custom syntax, however, we'd have to reserve even more keywords... at
 least, I assume. I suppose I should ask: what exactly are folks proposing
 to use in place of pragmas? It's hard to have this discussion without
 something concrete to reference.

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