Changes between Version 352 and Version 353 of TypeFunctionsStatus


Ignore:
Timestamp:
Jul 8, 2008 7:08:02 AM (6 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TypeFunctionsStatus

    v352 v353  
    3535 
    3636 * Misc: 
     37   * Test `Simple17` 
    3738   * #2291 (panic mixing RULES and type families; rule simplification stumbles over a coercion) 
    3839   * #714 (feature request: fundeps treated inconsistently in superclasses and type sigs) 
     
    9697   * 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). 
    9798 0. `:t` in ghci doesn't print equalities in contexts properly. 
    98  0. 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`. 
     99 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`. 
    99100 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`). 
    100101 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.