[GHC] #4361: Typechecker regression

[Serge D. Mechveliani]

On Wed, Jun 20, 2012 at 04:55:59PM -0000, GHC wrote:
> #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.
> 

All right.
Later, I shall try your two way outs for DoCon and report the result.

Regards,
Sergei