Changes between Version 392 and Version 393 of TypeFunctionsStatus


Ignore:
Timestamp:
Oct 2, 2008 8:41:24 AM (6 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TypeFunctionsStatus

    v392 v393  
    55'''Open bugs related to type families''' 
    66 
    7  * Well-formedness of declarations involving families: 
     7 * Declarations involving families: 
    88  * #1968 (GADT syntax in family instances; at least provide a proper error message and don't panic!) 
    99   * Need to check the result types of the data constructors, probably in `checkValidDataCon`. 
     
    1818  * #2435 (Bug with qualified names in declarations) 
    1919  * #2436 (Bad warning on export) 
     20  * Defaults for associated type synonyms.  (Having both a kind signature and vanilla synonym is problematic as in `RnNames.getLocalDeclBinders` its hard to see that not both of them are defining declarations, which leads to a multiple declarations error.  Defaults are quite different from vanilla synonyms anyway, as they usually have tyvars on their rhs that do not occur on the lhs.)  If an associated synonym has a default definition, use that in the instances.  In contrast to methods, this cannot be overridden by a specialised definition.  (Confluence requires that any specialised version is extensionally the same as the default.) 
    2021 
    2122 * Constraint simplification: 
    2223  * #2102 (superclass equalities) 
    2324    * To fix superclass equalities (specifically getting the coercion evidence), we could introduce a kind of typelet just for evidence.  In fact, re-use `HsBind.VarBind` and make its right-hand side a specially data structure describing evidence construction, instead of being a general `HsExpr`.  That evidence construction generation can have a case for extracting superclass constraints.  The desugarer than has to generate the case expression bringing the equality in scope from that. 
     25    * 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. 
    2426  * Rank-n types: In `TcTyFuns.flattenType`, we need to pull out type families below foralls. 
    2527  * Implicit parameters: In `TcTyFuns`, we need to normalise IP constraints, too (in `normDict` and `substDict`). 
     
    2729 
    2830 * GADT: 
    29   None. 
     31   * `gadt/lazypatok` needs to be fixed, but are irrefutable patterns really ok, see [http://okmij.org/ftp/Haskell/GADT-problem.hs]? 
     32   * It'd be nice if the error message of `tcfail167` would include "Inaccessible case alternative: Can't match types `Char' and `Float'" again.  We could achieve in `TcPat.tcConPat` by having a look at `eq_preds` in the GADT case.  If the `eq_preds` are obviously unsatisfiable (due to a clash of data type constructors), then we have an inaccessible case alternative. 
     33   * Rigidity: 
     34      * Shiuld test `GADT7` really succeed?  or is it ok to fail. 
     35      * Remove the dodgy rigidity test that is in `tcConPat` right now. 
     36      * implement the proposal where we infer a rigidity flag for case scutinees and pass that down when type checking the patterns. 
     37      * We infer the rigidity flag for the case scrutinee by generalising its type and checking whether that has any foralls at the top.  It's rigid if it has no foralls. 
     38      * As usual, if a pattern has a GADT constructor (ie, any constraints in the data constructor signature), the scutinee must be rigid, 
     39      * We  need to know of types whether they are rigid (not only whether they contain unification variables).  We can achieve that by a flag in the environment that indicates whether the computation of that type involved non-rigid type variables. 
    3040 
    3141 * Misc: 
     
    3545   * #1769 (deriving typeable for data families) 
    3646   * When a `type instance` changes (in an orphan modules), currently clients are not properly recompiled at least by `--make`. 
     47   * 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 why it is ok (i.e., they are never grouped together with `groupErrs` or similar). 
    3748   * #2296: error message involving fundep gives unhelpful location.  I want to remember to come back to this one when we have the new type-family simplification stuff in place. 
     49   * Fix export list problem (ie, export of data constructors introduced by orphan data instances): 
     50     * Change `HscTypes.IfaceExport` to use `Name` instead of `OccName`. 
     51     * Then, there is also no need for the grouping of the identifiers by module anymore (but sort it to avoid spurious iface changes dur to re-ordering when re-compiling). 
     52     * We still need to have the name parent map, though. 
     53     * See email for example. 
     54  * Eliminate code duplication between `tcTyClDecl1` and `tcFamInstDecl1`.  The code for vanilla data/newtype declarations and the code for data/newtype instances has many commonalities. 
    3855 
    3956'''Additional feature:''' 
     
    4562   * Step 2: Desugar FDs into TFs and superclass equalities. 
    4663  * ghci command to print normalised type and add [http://article.gmane.org/gmane.comp.lang.haskell.cafe/28799] as a test to the testsuite. 
    47  
    48 '''Debugging of type families:''' 
    49  0. Replacing GADT refinements by explicit equality constraints: 
    50     * Regressions that remain to be fixed:  
    51       * `gadt/lazypatok` needs to be fixed (are irrefutable patterns really ok, see http://okmij.org/ftp/Haskell/GADT-problem.hs]?) 
    52       * Error message of `tcfail167` should include "Inaccessible case alternative: Can't match types `Char' and `Float'" again 
    53     * Handling of cases expression scrutinising GADTs:  
    54       * See also test `GADT7` 
    55       * Remove the dodgy rigidity test that is in `tcConPat` right now. 
    56       * implement proposal where we infer a rigidity flag for case scutinees and pass that down when type checking the patterns, 
    57       * We infer the rigidity flag for the case scrutinee by generalising its type and checking whether that has an foralls at the top.  It's rigid if it has no foralls. 
    58       * if a pattern has a GADT constructor (ie, any constraints in the data constructor signature), the scutinee must be rigid, 
    59       * we  need to know of types whether they are rigid (not only whether they contain unification variables, but by a flag in the environment that indicates whether the computation of that type involved non-rigid type variables) 
    60     * Re `tcfail167`, SPJ proposes that could generate a better error message, at least most of the time.  If the "expected type" of a pattern is 's', and we meet a constructor with result type (T t1 ..tn), then one could imagine a 2-step process: 
    61       1. check that 's' is (or can be made to be) of form (T ....) 
    62       2. check that the ... can be unified with t1..tn 
    63       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. 
    64  0. Comments: 
    65    * 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). 
    66  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`. 
    67  0. Fix export list problem (ie, export of data constructors introduced by orphan data instances): 
    68    * Change `HscTypes.IfaceExport` to use `Name` instead of `OccName`. 
    69    * Then, there is also no need for the grouping of the identifiers by module anymore (but sort it to avoid spurious iface changes dur to re-ordering when re-compiling). 
    70    * We still need to have the name parent map, though. 
    71    * See email for example. 
    72  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. 
    73  0. Fix everything in the testsuite. 
    74  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. 
    75  0. Consider 
     64  * Most general signatures for record selectors: 
    7665{{{ 
    7766type family F a 
     
    8978  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. 
    9079 
     80----- 
    9181  
    9282== Parsing and Renaming ==