
#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