[GHC] #16321: Suggest -XScopedTypeVariables instead of -XRankNTypes

[GHC]

#16321: Suggest -XScopedTypeVariables instead of -XRankNTypes
-------------------------------------+-------------------------------------
           Reporter:  int-index      |             Owner:  (none)
               Type:  feature        |            Status:  new
  request                            |
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  8.6.3
  (Parser)                           |
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 When the parser encounters an explicit `forall` when `-XExplicitForAll` is
 disabled, it tries to guess what the user meant and suggests to enable
 `-XRankNTypes`:

 {{{
     Perhaps you intended to use RankNTypes or a similar language
     extension to enable explicit-forall syntax: forall <tvs>. <type>
 }}}

 Richard argues we are better off suggesting `-XScopedTypeVariables` by
 default:

 > Consider these workflows:
 >
 > 1a. User is writing a higher-rank type without extensions. GHC suggests
 to enable RankNTypes. Program is accepted.
 >
 > 1b. User is writing a higher-rank type without extensions. GHC suggests
 to enable ScopedTypeVariables. User compiles again, and GHC suggests to
 enable RankNTypes. Program is accepted.
 >
 > 2a. User is writing a program that requires scoped type variables. GHC
 suggests to enable RankNTypes. Program is rejected with inscrutable type
 errors claiming that `a` is not `a0`.
 >
 > 2b. User is writing a program that requires scoped type variables. GHC
 suggests to enable ScopedTypeVariables. Program is accepted.
 >
 > The question is: what's worse: 1b, or 2a? I claim that 2a is worse, and
 so I favor making the change so that we avoid 2a in favor of sometimes
 incurring 1b.

 The problem here is that in the grand scheme of things, we want neither 1b
 nor 2a to happen. What would it take to implement a proper diagnostic and
 always suggest the appropriate extension?

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