[GHC] #5910: Holes with other constraints

[GHC]

#5910: Holes with other constraints
----------------------------------------+-----------------------------------
    Reporter:  xnyhps                   |       Owner:                                   
        Type:  feature request          |      Status:  new                              
    Priority:  normal                   |   Milestone:                                   
   Component:  Compiler (Type checker)  |     Version:  7.5                              
    Keywords:  holes                    |          Os:  Unknown/Multiple                 
Architecture:  Unknown/Multiple         |     Failure:  Incorrect warning at compile-time
  Difficulty:  Unknown                  |    Testcase:                                   
   Blockedby:                           |    Blocking:                                   
     Related:                           |  
----------------------------------------+-----------------------------------

Comment(by simonpj):

 Thanks.  I’m pretty sure your proposed implementation is more complex than
 necessary. In particular, I don’t think you need all the `mkHoleName` and
 `HoleTyCon` stuff at all.   This machinery is needed for implicit
 parameters for one reason only, namely so that
 {{{
         f :: (?x :: Int) => Int -> Int
 }}}
 really has a different type to
 {{{
         f :: Int -> Int -> Int
 }}}
 Functions in GHC have one type, the Core type, so we need to have enough,
 robust information in that type to recover the Haskell type. Hence
 `(?x::Int)` is a different type to `Int`, and we explicitly cast between
 them.

 None of this is necessary for holes.  They are not part of the Haskell
 language, and we do not abstract over them.  So
  * The expression `_?a` really can have type `alpha` where `alpha` is a
 fresh unification variable.
  * You don't need `HolePred` in `PredTree`
  * You don't need any changes in `TyCon`, nor any of th complex stuff in
 `mkHoleName`.
  * You do still need `CHoleCan`; it's generated when you meet a hole `_?a`
 expression.

 Would you like to try that simplification?  That is, do NOT take implicit
 parameters as your guide!

 I agree that you don't want `-fdefer-type-errors` just because you have
 holes.  Just `-XHoles` should do, no?

 Simon

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