[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:  Other           
  Difficulty:  Unknown                  |    Testcase:                  
   Blockedby:                           |    Blocking:                  
     Related:                           |  
----------------------------------------+-----------------------------------

Comment(by xnyhps):

 About the simpler implementation:

  * `HoleName` was unnecessary, I agree (right now a hole name includes the
 "_?", so it can never collide with the name of a variable). I've removed
 it.
  * I've thought about this a lot, and went through the code, but I'm still
 not sure about your advice about `HolePred` and `HoleTyCon`. Right now,
 `tcExpr` emits a constraint (which is just a `Type`) when encountering a
 hole. Without `HoleTyCon`, I'm not sure how to find out a constraint was a
 hole-constraint, which is needed for it to turn into an `CHoleCan`.
 `classifyPredType` will reduce anything it doesn't recognize to a
 `IrredPred`, in which case it never solves anything. `canEvVar` (with
 `canHole`) needs to see a `HolePred` to make it an `CHoleCan`.

  (Do you perhaps mean: generate a fresh tyvar for every hole, and every
 time a hole is encountered, emit an `Eq` constraint between this tyvar and
 the type it needs at that location? In that case, a lot of what's added
 could be removed, even `CHoleCan` would not be needed anymore, but it
 would need a new way of reporting the holes as they are no longer separate
 constraints.)


 ----

 About the original problem of ambiguous constraints:

  * We currently have a solution that uses `tyVarsOfCt` to find out which
 class-ambiguity errors apply to tyvars that also occur in hole-"errors",
 and automatically defers those as well. I'm not sure this is a very robust
 solution, but it seems to solve the problem.

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