[GHC] #10607: Auto derive from top to bottom

GHC ghc-devs at haskell.org
Fri Mar 23 16:06:32 UTC 2018


#10607: Auto derive from top to bottom
-------------------------------------+-------------------------------------
        Reporter:  songzh            |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.11
      Resolution:                    |             Keywords:  deriving,
                                     |  typeclass, auto
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #13324            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Ryan Scott <ryan.gl.scott@…>):

 In [changeset:"affdea82bb70e5a912b679a169c6e9a230e4c93e/ghc"
 affdea82/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="affdea82bb70e5a912b679a169c6e9a230e4c93e"
 Allow PartialTypeSignatures in standalone deriving contexts

 Summary:
 At its core, this patch is a simple tweak that allows a user
 to write:

 ```lang=haskell
 deriving instance _ => Eq (Foo a)
 ```

 Which is functionally equivalent to:

 ```lang=haskell
 data Foo a = ...
   deriving Eq
 ```

 But with the added flexibility that `StandaloneDeriving` gives you
 (namely, the ability to use it anywhere, not just in the same module
 that `Foo` was declared in). This fixes #13324, and should hopefully
 address a use case brought up in #10607.

 Currently, only the use of a single, extra-constraints wildcard is
 permitted in a standalone deriving declaration. Any other wildcard
 is rejected, so things like
 `deriving instance (Eq a, _) => Eq (Foo a)` are currently forbidden.

 There are quite a few knock-on changes brought on by this change:

 * The `HsSyn` type used to represent standalone-derived instances
   was previously `LHsSigType`, which isn't sufficient to hold
   wildcard types. This needed to be changed to `LHsSigWcType` as a
   result.

 * Previously, `DerivContext` was a simple type synonym for
   `Maybe ThetaType`, under the assumption that you'd only ever be in
   the `Nothing` case if you were in a `deriving` clause. After this
   patch, that assumption no longer holds true, as you can also be
   in this situation with standalone deriving when an
   extra-constraints wildcard is used.

   As a result, I changed `DerivContext` to be a proper datatype that
   reflects the new wrinkle that this patch adds, and plumbed this
   through the relevant parts of `TcDeriv` and friends.

 * Relatedly, the error-reporting machinery in `TcErrors` also assumed
   that if you have any unsolved constraints in a derived instance,
   then you should be able to fix it by switching over to standalone
   deriving. This was always sound advice before, but with this new
   feature, it's possible to have unsolved constraints even when
   you're standalone-deriving something!

   To rectify this, I tweaked some constructors of `CtOrigin` a bit
   to reflect this new subtlety.

 This requires updating the Haddock submodule. See my fork at
 https://github.com/RyanGlScott/haddock/commit/067d52fd4be15a1842cbb05f42d9d482de0ad3a7

 Test Plan: ./validate

 Reviewers: simonpj, goldfire, bgamari

 Reviewed By: simonpj

 Subscribers: goldfire, rwbarton, thomie, mpickering, carter

 GHC Trac Issues: #13324

 Differential Revision: https://phabricator.haskell.org/D4383
 }}}

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


More information about the ghc-tickets mailing list