Changes between Version 397 and Version 398 of TypeFunctionsStatus

Timestamp:

10/04/08 05:25:03 (5 years ago)

Author:

chak

Comment:

--

TypeFunctionsStatus

@@ -8 +8 @@
 
  * Declarations involving families:
+  * Test`Simple8`:
+   * Fix tcLookupFamInst to gracefully handle this case.  (This requires some care to not violate assumptions made by other  clients of this function, as it is also used for data families,  but I see no fundamental problem.)
+   * Issue a warning if there are two identical instances (as per  Roman's suggestion).
   * #1968 (GADT syntax in family instances; at least provide a proper error message and don't panic!)
    * Need to check the result types of the data constructors, probably in `checkValidDataCon`.
    * `tcFamInstDecl1` needs to allow family GADT instances.
-  * Test`Simple8`:
-   * Fix tcLookupFamInst to gracefully handle this case.  (This requires some care to not violate assumptions made by other  clients of this function, as it is also used for data families,  but I see no fundamental problem.)
-   * Issue a warning if there are two identical instances (as per  Roman's suggestion).
   * #2203 (TFs in class instance heads)
   * #2435 (Bug with qualified names in declarations)
-  * #2436 (Bad warning on export)
   * 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.)
 
@@ -28 +27 @@
 
  * GADT:
-   * `gadt/lazypatok` needs to be fixed, but are irrefutable patterns really ok, see [http://okmij.org/ftp/Haskell/GADT-problem.hs]?
-   * 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.
-   * Rigidity:
-      * Shiuld test `GADT7` really succeed?  or is it ok to fail.
-      * Remove the dodgy rigidity test that is in `tcConPat` right now.
-      * implement the proposal where we infer a rigidity flag for case scutinees and pass that down when type checking the patterns.
-      * 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.
-      * As usual, if a pattern has a GADT constructor (ie, any constraints in the data constructor signature), the scutinee must be rigid,
-      * 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.
+  * `gadt/lazypatok` needs to be fixed, but are irrefutable patterns really ok, see [http://okmij.org/ftp/Haskell/GADT-problem.hs]?
+  * 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.
+  * Rigidity:
+     * Shiuld test `GADT7` really succeed?  or is it ok to fail.
+     * Remove the dodgy rigidity test that is in `tcConPat` right now.
+     * implement the proposal where we infer a rigidity flag for case scutinees and pass that down when type checking the patterns.
+     * 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.
+     * As usual, if a pattern has a GADT constructor (ie, any constraints in the data constructor signature), the scutinee must be rigid,
+     * 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.
 
  * Misc:
-   * Test `Simple17` (corelint error as a dict binding, used to specialise a call to a local function, floats out too far)
-   * Improve error messages for loopy equalities: TF tests `Simple13` & `SkolemOccursLoop`
-   * #1897: If you infer a type for a function, then should check the function against that sigature, to check that if the user gave that signature, then typechecking would again succeed.  See this thread http://www.haskell.org/pipermail/haskell-cafe/2008-April/041385.html.
-   * #1769 (deriving typeable for data families)
-   * When a `type instance` changes (in an orphan modules), currently clients are not properly recompiled at least by `--make`.
-   * 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).
-   * #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.
-   * Fix export list problem (ie, export of data constructors introduced by orphan data instances):
-     * Change `HscTypes.IfaceExport` to use `Name` instead of `OccName`.
-     * 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).
-     * We still need to have the name parent map, though.
-     * See email for example.
-   * Eliminate code duplication between `tcTyClDecl1` and `tcFamInstDecl1`.  The code for vanilla data/newtype declarations and the code for data/newtype instances has many commonalities.
+  * Test `Simple17` (corelint error as a dict binding, used to specialise a call to a local function, floats out too far)
+  * Improve error messages for loopy equalities: TF tests `Simple13` & `SkolemOccursLoop`
+  * #1897: If you infer a type for a function, then should check the function against that sigature, to check that if the user gave that signature, then typechecking would again succeed.  See this thread http://www.haskell.org/pipermail/haskell-cafe/2008-April/041385.html.
+  * #1769 (deriving typeable for data families)
+  * When a `type instance` changes (in an orphan modules), currently clients are not properly recompiled at least by `--make`.
+  * 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).
+  * #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.
+  * Fix export list problem (ie, export of data constructors introduced by orphan data instances):
+    * Change `HscTypes.IfaceExport` to use `Name` instead of `OccName`.
+    * 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).
+    * We still need to have the name parent map, though.
+    * See email for example.
+  * #2436 (Bad warning on export)
+  * Eliminate code duplication between `tcTyClDecl1` and `tcFamInstDecl1`.  The code for vanilla data/newtype declarations and the code for data/newtype instances has many commonalities.
 
 '''Additional feature:'''