[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