#14288: ScopedTypeVariables with nested foralls broken since 8.0.2 -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): comment:13 has it. That's why it's strange. When I program in Haskell, I implicitly believe I'm programming in something quite like F_omega, but the compiler puts in gobs of annotations. And I find it disturbing and strange when the compiler rearranges my expressions. Also, what happens when you replace the right-hand side of the expression with `undefined`? Consider {{{#!hs f3 :: forall a b. a -> Int -> (a, b) f3 x = undefined f4 :: forall a. a -> Int -> forall b. (a, b) f4 x = undefined }}} Evaluating {{{f3 True `seq` ()}}} diverges, while {{{f4 True `seq` ()}}} returns `()`. This is because `f4 True` is really a lambda, due to the parameter-swizzling. I argue once we have a proper story for visible type patterns, `f4 True` will also be able to diverge, and then my original example becomes ever stranger. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14288#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler