[GHC] #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x)

[GHC]

#15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x)
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler (Type    |              Version:  8.5
  checker)                           |             Keywords:
      Resolution:                    |  QuantifiedConstraints
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 goldfire):

 But this is done for ordinary constraints, right in the parser. Here is s
 slice of RdrHsSyn:

 {{{#!hs
 checkContext :: LHsType GhcPs -> P ([AddAnn],LHsContext GhcPs)
 checkContext (L l orig_t)
   = check [] (L l orig_t)
  where
   check anns (L lp (HsTupleTy _ HsBoxedOrConstraintTuple ts))
     -- (Eq a, Ord b) shows up as a tuple type. Only boxed tuples can
     -- be used as context constraints.
     = return (anns ++ mkParensApiAnn lp,L l ts)                -- Ditto ()
   ...
 }}}

 Sadly, I don't think we can just do this in the parser, as it would really
 complicate the AST. But then we should perhaps directly reject `forall x.
 ( ... , ... )` as it won't mean what the user wants. I still favor the
 rewrite, but I think that, failing that, we should error more cleanly.

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