[GHC] #12418: Make `MonadCont (ContT r m)` polykinded (r::k), (m::k -> Type)
GHC
ghc-devs at haskell.org
Thu Aug 11 11:01:25 UTC 2016
#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
More information about the ghc-tickets
mailing list