[GHC] #4361: Typechecker regression

[GHC]

#4361: Typechecker regression
---------------------------------------------+------------------------------
  Reporter:  igloo                           |          Owner:  simonpj         
      Type:  bug                             |         Status:  closed          
  Priority:  high                            |      Milestone:  7.0.1           
 Component:  Compiler (Type checker)         |        Version:  7.1             
Resolution:  fixed                           |       Keywords:                  
        Os:  Unknown/Multiple                |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown                    |     Difficulty:  Unknown         
  Testcase:  typecheck/should_compile/T4361  |      Blockedby:                  
  Blocking:                                  |        Related:                  
---------------------------------------------+------------------------------
Changes (by simonpj):

 * cc: mechvel@… (added)


Comment:

 With all the changes to type inference engine, it has become apparent that
 the hack I put in to solve Serge's problem is indeed a GROSSLY UNSAVOURY
 HACK.
  * It is extremely fragile.  It only solves the problem in a special case,
 so the very same problem will arise again in a somewhat more complicated
 program.
  * It takes quite a bit of code.
  * It has increasingly unpleasant knock-on effects.  Eg `IPRun` has
 started failing because a special case for implicit parameters has been
 removed. But the special case itself was only needed because of the
 GROSSLY UNSAVOURY HACK.

 The hack is described in `Note [Avoid unecessary constraint
 simplification]` above. I'm taking it out, which will make !DoCon fail to
 compile. The culprit is local let generalisation (see
 [http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 my blog
 post]).  Happily, it's extremely easy to fix your source code in either of
 these two ways:

  * If you use `-XMonoLocalBinds` (which is in any case implied by
 `-XGADTs` and `-XTypeFamilies`), then GHC won't generalise the definition
 of `x` in the example, and all will be well.

  * Alterantively, give a type signature for `x`, thus (in this case)
 {{{
 moduloBasisx p = let x :: ()
                      x = upLinSolvRing p
                  in ()
 }}}
  Doing so means that generalisation does not happen, and the constraints
 are solved outside-in, as is really desired.

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