[GHC] #13368: Derive superclasses automatically if possible

[GHC]

#13368: Derive superclasses automatically if possible
-------------------------------------+-------------------------------------
        Reporter:  Iceland_jack      |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #10607            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by RyanGlScott):

 This proposal shares many similarities with the
 [https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses
 IntrinsicSuperclasses] and
 [https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates
 InstanceTemplates] proposals, so I'll link them here. However, this
 proposal shares many of their downsides, which I'll briefly expound upon
 here.

 First, there's the technical challenges to this proposal. Not all
 instances are made equal, and `deriving` exposes this in many ways. For
 instance, suppose you tried this under your proposal:

 {{{#!hs
 class Traversable f => Witherable f where ...

 newtype Wrapped f a = Wrap (f a)
   deriving newtype Witherable
 }}}

 This would attempt the following:

 * `deriving newtype instance Functor f => Functor (Wrapped f)`
 * `deriving newtype instance Foldable f => Foldable (Wrapped f)`
 * `deriving newtype instance Traversable f => Traversable (Wrapped f)`
 * `deriving newtype instance Witherable f => Witherable (Wrapped f)`

 But trying to derive `Traversable` that way will fail, as it is ill-roled!
 See #13153. So not only would this throw an error, but it would throw an
 error that talks about a completely different class than `Witherable`.
 Mysterious.

 What's more, there's quite a number of ambiguities you'd have to deal
 with. For instance, what happens under your proposal in this scenario?

 {{{#!hs
 class Show a => MyShow a where ...

 data Foo
   deriving newtype MyShow

 instance Show Foo
 }}}

 Since `Show` is a superclass of `MyShow`, you might expect the `deriving
 newtype MyShow` clause to derive `instance Show Foo` as well. But there's
 already an `instance Show Foo`! So we'd either have to error here, or come
 up with a scheme for defaulting to existing instances when scenarios like
 the above one crop up.

 You might respond: "But that's easy! Just use the existing `Show Foo`
 instance!" But it gets even hairier than that:

 {{{#!hs
 class Show a => MyShow1 a where ...
 class Show a => MyShow2 a where ...

 data Foo
   deriving newtype MyShow1
   deriving anyclass MyShow2
 }}}

 Now we must ask: which of the two deriving clauses will implicitly derive
 `Show` behind the scenes? The choice matters, because a `newtype`-derived
 `Show` instance will be completely different than an `anyclass`-derived
 one! If the answer to this question is "use the first deriving clause",
 then now the order in which you write `deriving` clauses matters, which is
 a property that Haskell has never had up to this point.

 Finally, there's one more objection I will make not on technical grounds,
 but on aesthetic ones. This proposal would lose the property that all
 instances are explicitly asked for by the user. I (personally) find the
 idea of instances being snuck in behind the scenes quite shady and hard to
 reason about, and in addition, we'd lose things like concrete source
 locations for every instance, the ability to annotate all instances with
 Haddocks, etc.

 So my opinion in that it's a huge amount of complexity for very little
 gain and many drawbacks. I like the idea of doing something like this in
 Template Haskell, so I'm glad that someone is pursuing this in #10607.

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