#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