Changes between Version 354 and Version 355 of TypeFunctionsStatus


Ignore:
Timestamp:
Jul 8, 2008 7:44:09 AM (7 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TypeFunctionsStatus

    v354 v355  
    3636 
    3737 * Misc: 
    38    * Test `Simple17` 
     38   * Test `Simple17` & `GADT12` (corelint errors) 
    3939   * #2291 (panic mixing RULES and type families; rule simplification stumbles over a coercion) 
    4040   * #714 (feature request: fundeps treated inconsistently in superclasses and type sigs) 
     
    9999   * When we raise a mismatch error in `TcSimplify` for unresolvable equalities, we effectively tidy the two non-matching types twice.  Add a comment to highlight this and say way it is ok (i.e., they are never grouped together with `groupErrs` or similar). 
    100100 0. `:t` in ghci doesn't print equalities in contexts properly. 
    101  0. RankN: When can foralls appear in equalities?  What constraints does that place on GADTs?  Also, the code in `TcTyFuns` doesn't really deal with rank-n types properly, esp `decompRule`.  Also test `Simple14`. 
     101 0. RankN: When can foralls appear in equalities?  What constraints does that place on GADTs?  Also, the code in `TcTyFuns` doesn't really deal with rank-n types properly, esp `decompRule`.  Also test `Simple14` & `GADT10`. 
    102102 0. CONCEPTUAL issue: At least with `skolemOccurs`, the policy of not zonking the types embedded in the kinds of coercion type variables does no longer work.  This becomes, for example in the test `Simple13`, apparent.  The skolem introduced in `skolemOccurs` finds its way into variable kinds (which is visible when inspecting them during `TcMType.zonk_tc_tyvar`). 
    103103 0. When `Simple13` is compiled with a compiler that was built with `-DDEBUG`, it prints a warning about not matching types being used during constructing a trans coercion.