#5609: Type checking arrow notation in the presence of deferred constraints
---------------------------------+------------------------------------------
    Reporter:  dreixel           |       Owner:                         
        Type:  bug               |      Status:  new                    
    Priority:  normal            |   Component:  Compiler (Type checker)
     Version:  7.3               |    Keywords:                         
    Testcase:                    |   Blockedby:                         
          Os:  Unknown/Multiple  |    Blocking:                         
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown           
---------------------------------+------------------------------------------
 In `TcArrows`, the following code

 {{{
     tc_cmd w_tv (cmd, i, b, tup_ty, s)
       = do { tup_ty' <- zonkTcType tup_ty
            ; let (corner_ty, arg_tys) = unscramble tup_ty'

                 -- Check that it has the right shape:
                 --      ((w,s1) .. sn)
                 -- where the si do not mention w
            ; checkTc (corner_ty `eqType` mkTyVarTy w_tv &&
                       not (w_tv `elemVarSet` tyVarsOfTypes arg_tys))
                      (badFormFun i tup_ty')

            ; tcCmdTop (env { cmd_arr = b }) cmd arg_tys s }
 }}}

 is wrong. In particular, the check `elemVarSet w_tv (tyVarsOfTypes
 arg_tys)` does not make sense in the presence of deferred constraints.

 There is no testcase for this at the moment, but in the ghc-kinds branch
 both T5283 and arrowform1 fail because of this. The temporary fix was:
 {{{
            ; _bogus <- unifyType corner_ty (mkTyVarTy w_tv)
            ; checkTc (not (w_tv `elemVarSet` tyVarsOfTypes arg_tys))
                      (badFormFun i tup_ty')
 }}}

 This solves only T5283 and arrowform1; other problems might arise in the
 future, so this should be fixed properly.

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

_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to