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

Sep 20, 2013 3:48:07 PM (18 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.