[GHC] #2044: "Can't unify" error in debugger

[GHC]

#2044: "Can't unify" error in debugger
--------------------+-------------------------------------------------------
 Reporter:  r6144   |          Owner:  mnislaih
     Type:  bug     |         Status:  assigned
 Priority:  normal  |      Milestone:  6.8.3   
Component:  GHCi    |        Version:  6.8.2   
 Severity:  normal  |     Resolution:          
 Keywords:          |     Difficulty:  Unknown 
 Testcase:          |   Architecture:  x86     
       Os:  Linux   |  
--------------------+-------------------------------------------------------
Changes (by mnislaih):

  * status:  new => assigned
  * owner:  pepe => mnislaih

Comment:

 Thanks for CC'ing, I had missed this ticket.

 At first I though this problem was an instance of #1995, but it turns out
 your suspicion was right.
 The RTTI mechanism panics when trying to reconstruct the type for buildBuf
 in line 3.
 This is the 'full' error obtained via initTcPrintErrors :

 {{{
 Top level:
     Cannot match a monotype with `ST s (forall s'. ST s' (STUArray s' Idx
 Double))'
       Expected type: ST s (forall s'. ST s' (STUArray s' Idx Double))
       Inferred type: t
 ghc-6.9.20080404: panic! (the 'impossible' happened)
   (GHC version 6.9.20080404 for i386-apple-darwin):
         Can't unify
 }}}

 So GHC is refusing to unify the tyvar with an impredicative type. This
 tyvar is created as follows:
 {{{
 newVar kind = mkTyVarTy `fmap` newFlexiTyVar kind
 }}}
 in this case with kind argType.

 How should the tyvars used by the RTTI mechanism be created to handle this
 situation ?

 And, do we need to handle it at all?
 At runtime we handle values, which are monomorphically typed. It looks to
 me that the type recovered for buildBuf should be just:

 {{{
 buildBuf :: ST s (ST s' (STUArray s' Idx Double)
 }}}

 Does that make sense?

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