#16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): For reference, here is why `check_pred_ty` rejects the program in this ticket under the new-and-improved type validity-checker. We start with this type: {{{#!hs (Functor f, F1 f) }}} `check_pred_ty` calls `check_ty`, at which point we discover that this type is headed by a constraint tuple type constructor, so we call `check_arg_type` on each of its arguments. As a consequence, we switch the `ve_rank` in the `ValidityEnv` to `tyConArgMonoType`. We eventually check `F1 f` and, in turn, check `forall a. Eq (f a)` using `check_type` (if we were using the old type validity-checker, we would have stopped at `F1 f`!). Since `forall a. Eq (f a)` is a polytype, we must check it using `forAllAllowed ve_rank`. But our `ve_rank` is still `tyConArgMonoType`, and `forAllAllowed` returns `False` for `MonoType`s! So GHC ultimately decides to reject it. ----- What can be done about this? One conceivable route is to add a special case to `check_type` for applications of constraint tuple type constructors and, if so, don't call `check_arg_type` and instead call some other function which ensures that `ve_rank` is permissive enough to handle polytypes. There is precedent for this already—see `check_ubx_tuple`. On the other hand, I don't think this would fix the problem entirely. The issue is that we want to accept this: {{{#!hs f :: (Functor f, forall a. Eq (f a)) => Int }}} While simultaneously rejecting this: {{{#!hs g :: Proxy (Functor f, forall a. Eq (f a)) -> Int }}} But in both cases, `forall a. Eq (f a)` is directly underneath an application of a constraint tuple tycon, so if we always switch `ve_rank` to something permissive whenever we detect an application of a constraint tuple tycon, then I believe that GHC would accept //both// programs, which isn't what we want. I think that we a finer-grained criterion than this, but I'm not sure what that would be... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16140#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler