Changes between Version 68 and Version 69 of Records/OverloadedRecordFields/Implementation

Sep 20, 2013 3:48:07 PM (23 months ago)



  • Records/OverloadedRecordFields/Implementation

    v68 v69  
    250250* Where should `TcBuiltInSynFamily` live? Could it be a fixed enumeration?
    251 * Is `TcInstDcls.tcFldInsts` correct in its use of `simplifyTop` and assuming there will be no `ev_binds`?
     252* It should be possible to remove the `tcg_axioms`, `mg_axioms` and `ic_axioms` fields, and instead use `tcg_tcs` when we need to get hold of the axioms in `TidyPgm`.  However, this  requires `FieldLabel`s (stored in `TyCon`s) to contain the actual `CoAxiom`s, not just their `Name`s, which in turn requires more refactoring.  Also note that universally quantified fields will not have axioms.
     253* Make record selector bindings in `TcFldInsts`?
     254* We shouldn't need to mess with the `TypeEnv` in `tcRnHsBootDecls`. Instead:
     255  1. `tcTyClsInstDecls` should populate it with the `dfun_ids`
     256  2. `tcHsBootSigs` should populate it with `val_ids` and return an updated `TcGblEnv`
     257  3. Add a new field `tcg_boot_ids :: Bag Id` to `TcGblEnv` and pass `val_ids` to `mkBootModDetailsTc` that way, so it doesn't need to use the `TypeEnv`
     258* We now generate `r { foo :: ... }` in the pretty-printer, but should we accept it in the parser?  What if the supressed type is `GetResult s "foo"` for a different type s?
     259* Fuse `makeRecFldInstsFor` and `tcFldInsts`, or just generate and typecheck binds.  Use `tcValBinds` or similar for the typechecking.
    252261* Consider defaulting `Accessor p` to `p = (->)`, and defaulting `Has r "f" t` constraints where there is only one datatype with a field `f` in scope.
    253262* We could add `HsVarOut RdrName id` instead of `HsSingleRecFld` (or perhaps rename `HsVar` to `HsVarIn`). This would also be useful to recall how the user referred to something.
    254 * Add syntax for record projection? When we have explicit type application, one might be able to use `field @"foo"` or `getField @"foo"`.
     263* Add syntax for record projection, perhaps using # since it shouldn't conflict with `MagicHash`? When we have explicit type application, one might be able to use `field @"foo"` or `getField @"foo"`. Document the options.