Changes between Version 349 and Version 350 of TypeFunctionsStatus


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

--

Legend:

Unmodified
Added
Removed
Modified
  • TypeFunctionsStatus

    v349 v350  
    3333 * Misc: 
    3434   * #2418 (desguaring type functions to constraints changes behaviour) 
    35    * #2417 (using GADT-style syntax causes panic) 
    3635   * #2291 (panic mixing RULES and type families; rule simplification stumbles over a coercion) 
    3736   * #714 (feature request: fundeps treated inconsistently in superclasses and type sigs) 
     
    6463   * Clean up `TcSimplify.reduceContext` and try to get rid of of having two loops, namely the ones used in `TcTyFuns` and the one implemented by `checkLoop`. 
    6564   * `substEqInDict` needs to be symmetric (i.e., also apply right-to-left rules); try to re-use existing infrastructure.  It would be neater, easier to understand, and more efficient to have one loop that goes for a fixed point of simultaneously rewriting with given_eqs, wanted_eqs, and type instances. 
    66    * skolemOccurs for wanteds?  At least `F a ~ [G (F a)]` and similar currently result in an occurs check error.  Without skolemOccurs in wanted, the occurs check for wanted would need to be smarter (and just prevent cyclic substitutions of the outlined form silently).  However, when inferring a type, having the rewrites enabled by skolemOccurs available will leads to potentially simpler contexts.  As an example consider 
     65   * skolemOccurs for wanteds?  At least `F a ~ [G (F a)]` and similar currently result in an occurs check error.  Without skolemOccurs in wanted, the occurs check for wanted would need to be smarter (and just prevent cyclic substitutions of the outlined form silently).  However, when inferring a type, having the rewrites enabled by skolemOccurs available will leads to potentially simpler contexts.  As an example that is rejected if the signature for `test` is present, but accepted if the signature is omitted (and inferred), consider 
    6766{{{ 
    6867type family F x 
     
    7877test x = t x (f x) 
    7978}}} 
    80   It is reject if the signature for `test` is present, but accepted if the signature is omitted (and inferred). 
    8179 0. Replacing GADT refinements by explicit equality constraints: 
    8280    * Regressions that remain to be fixed:  
     
    9290      1. check that 's' is (or can be made to be) of form (T ....) 
    9391      2. check that the ... can be unified with t1..tn 
    94      If (1) succeeds but (2) fails, the alternative is in accessible.  Of course, (2) might fail "later" by generating a constraint that later can't be satisfied, and we won't report that well, but we'd get a good message in the common fails-fast case.  We could even improve the message from (1) to say: "Constructor C is from data type T, but a pattern of type s is expected. 
     92      If (1) succeeds but (2) fails, the alternative is in accessible.  Of course, (2) might fail "later" by generating a constraint that later can't be satisfied, and we won't report that well, but we'd get a good message in the common fails-fast case.  We could even improve the message from (1) to say: "Constructor C is from data type T, but a pattern of type s is expected. 
    9593 0. Comments: 
    9694   * 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). 
     
    111109 0. Eliminate code duplication between `tcTyClDecl1` and `tcFamInstDecl1`.  The code for vanilla data/newtype declarations and the code for data/newtype instances has many commonalities. 
    112110 0. Fix everything in the testsuite. 
    113  0. Can't we now allow non-left-linear declarations; e.g., `instance type F a a = ..`? 
    114111 0. The tests `tcfail068` and `rw` used to raise more type errors right away.  Now, we see less recovery. 
    115112 0. What about filtering the `EqInst`s in `TcSimplify.addSCs`.  We need them, don't we?  But they give rise to `Var`s, not `Id`s, and we haven't got selectors. 
     
    128125upd :: T a b -> c -> T a c 
    129126}}} 
    130   It seems a bit complicated to come up with the most general type.  THe relevant code is in `TcExpr.tcExpr` in STEP 4 of the `RecordUpd` case. 
     127  It seems a bit complicated to come up with the most general type.  The relevant code is in `TcExpr.tcExpr` in STEP 4 of the `RecordUpd` case. 
    131128 0. Can we support 
    132129{{{ 
     
    143140eq_elim EQUAL p = p  
    144141}}} 
     142 
    145143  
    146 '''Current:''' 
    147  * Add some trac wiki documentation of how inference with type families works. 
    148  
    149144== Parsing and Renaming == 
    150145