[GHC] #12418: Make `MonadCont (ContT r m)` polykinded (r::k), (m::k -> Type)

[GHC]

#12418: Make `MonadCont (ContT r m)` polykinded (r::k), (m::k -> Type)
-------------------------------------+-------------------------------------
        Reporter:  Iceland_jack      |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Core Libraries    |              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:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by ekmett):

 > So perhaps CLC should do as you implicitly suggest?

 I very deliberately didn't suggest that. I actually pointed it out as a
 sign of quite how bad it would be to do this. It would affect every single
 user defined monad transformer type that happens to lift over `ContT` as
 well. Not just code in `transformers`. This would fix the inference for
 the handful of instances `transformers` defines, but not for every other
 package out there that builds on top.

 For the record, I'm pretty strongly against this proposal from the
 standpoint of what it does in practice to what is currently a very stable
 part of our ecosystem.

 A single combinator gets a slightly more general signature, but the result
 is that the `ContT` type becomes worse at its original stated job as
 serving as a monad transformer. Given that it comes from
 `Control.Monad.Trans.Cont`, it seems it is well placed for the current
 design.

 The replacement doesn't actually offer any new uses. If you use it at the
 new kind almost none of the existing instances are useful and they in fact
 actively get in the way of anything more generic you might want by
 overlapping these hypothetical instances for hypothetical classes we don't
 have.

 This is a situation where a different type offered by a different library
 is in order.

 The compromise of adding a ton of constraints is worse than the compromise
 of simply not PolyKinding the data type in the first place, as it impacts
 both the existing users badly _and_ whatever potential users the more
 general form woudl have, as if you wanted to use the power to do something
 more interesting the instance of these blanket instances would likely
 prevent you from doing it anyways.

 If you want the power of this proposal you can get it by just using `Cont
 (IdentityT m r) a` out of the box today. It has every single one of the
 admissible instances that would be let through by this proposal.
 `IdentityT` is already PolyKinded, but doesn't cause these sorts of
 problems.

 I'm inclined to close this out until the unlikely day when there is a
 library out there that shows the change, and people out there who see a
 need to use it.

 @Iceland_jack, I'm sorry, but would you object terribly strongly to that
 resolution?

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