[GHC] #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving

[GHC]

#9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.8.1
       Component:  Compiler (Type    |              Version:  7.8.2
  checker)                           |             Keywords:  Roles,
      Resolution:                    |  QuantifiedConstraints
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:  quantified-
                                     |  constraints/T9123{,a}
      Blocked By:  15290             |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 > If we wanted to do this (and I'm waiting for Simon to say that we don't)

 I don't!  It's pretty much always possible to take all the constraints
 needed for the constructors to typecheck, and spit them out as the
 instance context. Bingo - the instance typechecks. But we don't always
 want to do that.  E.g.  If we need `Int ~ Bool` we probably don't want to
 quantify over that.

 In fact GHC is pretty conservative: `Note [Exotic derived instance
 contexts]` in `TcDerivInfer`.   One could make it less conservative
 provided you still obeyed the termination conditions.

 Generally we are pretty conservative, even for ordinary functions in
 `tcSimplifyInfer`, where we have no termination conditions to worry about.
 See `pickQuantifiablePreds` in `TcType`.  We don't even ''try'' to
 quantify over a quantified constraint.

 Before quantifying over quantified constraints in instances, we should
 consider it for the simpler case of ordinary functions.  And I frankly
 doubt it'll be feasible in practice.

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