[GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes

[GHC]

#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