[GHC] #14288: ScopedTypeVariables with nested foralls broken since 8.0.2

[GHC]

#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