Changes between Version 71 and Version 72 of Records/OverloadedRecordFields/Implementation


Ignore:
Timestamp:
Feb 15, 2014 2:17:44 PM (14 months ago)
Author:
adamgundry
Comment:

Back to three parameters

Legend:

Unmodified
Added
Removed
Modified
  • Records/OverloadedRecordFields/Implementation

    v71 v72  
    11= Overloaded record fields: implementation notes = 
    22 
    3 Here be dragons. This page describes implementation details and progress on the implementation of [wiki:Records/OverloadedRecordFields/Plan the overloaded record fields plan]. Development of the extension is taking place on forks of the [https://github.com/adamgundry/ghc ghc], [https://github.com/adamgundry/packages-base packages-base], [https://github.com/adamgundry/haddock haddock] and [https://github.com/adamgundry/testsuite testsuite] repositories (on branch 'overloaded-record-fields'). A [https://github.com/adamgundry/records-prototype/blob/master/RecordsPrototype.hs prototype implementation] is also available. 
     3Here be dragons. This page describes implementation details and progress on the implementation of [wiki:Records/OverloadedRecordFields/Plan the overloaded record fields plan]. Development of the extension is taking place on forks of the [https://github.com/adamgundry/ghc ghc], [https://github.com/adamgundry/packages-base packages-base] and [https://github.com/adamgundry/haddock haddock] repositories (on branch 'overloaded-record-fields'). A [https://github.com/adamgundry/records-prototype/blob/master/RecordsPrototype.hs prototype implementation] is also available. 
    44 
    55== The basic idea == 
     
    1919$sel:x:T (MkT x) = x 
    2020 
    21 $dfHasTx :: Has T "x" -- corresponds to the Has instance decl 
     21$dfHasTx :: forall a . a ~ Int => Has T "x" b -- corresponds to the Has instance decl 
    2222$dfHasTx = Has { getField _ = $sel_x_T } 
    2323 
     
    222222 
    223223{{{ 
    224 instance Has (F Int) "foo" 
    225 instance Has (F Bool) "foo" 
     224instance b ~ Int  => Has (F Int)  "foo" b 
     225instance b ~ Bool => Has (F Bool) "foo" b 
    226226}}} 
    227227 
     
    248248 
    249249 
    250 == To do == 
    251  
    252 * The definition of `tcFldInsts` is currently wrong, because with the new design, the constraint solver needs to generate evidence bindings. Where should these go? It should be possible to fuse `makeRecFldInstsFor` and `tcFldInsts`, or just generate and typecheck binds, using `tcValBinds` or similar for the typechecking. 
    253  
    254 * Where should `TcBuiltInSynFamily` live? Could it be a fixed enumeration? 
    255  
     250== Outstanding issues == 
     251 
     252* The definition of `tcFldInsts` has a slightly fragile assertion that it does not obtain any evidence bindings when typechecking `Has`/`Upd` instances. Could these be returned somewhere instead? It should be possible to fuse `makeRecFldInstsFor` and `tcFldInsts`, or just generate and typecheck binds, using `tcValBinds` or similar for the typechecking. 
    256253* 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. 
    257 * Make record selector bindings in `TcFldInsts`? 
     254* We contemplated making the `CoAxioms` `implicitTyThings`, but I got stuck trying to do this because of the "Tricky iface loop" (see note in `LoadIface`). 
     255* Perhaps we should make record selector bindings in `TcFldInsts`, along with the new code. 
    258256* We shouldn't need to mess with the `TypeEnv` in `tcRnHsBootDecls`. Instead: 
    259257  1. `tcTyClsInstDecls` should populate it with the `dfun_ids` 
    260258  2. `tcHsBootSigs` should populate it with `val_ids` and return an updated `TcGblEnv` 
    261259  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` 
    262 * Pretty-printing needs to be sorted out for the new design with a two-parameter Has class 
    263  
    264260* Consider defaulting `Accessor p r n` to `p = (->)`, and defaulting `Has r "x"` constraints where there is only one datatype with a field `x` in scope. 
    265261* 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.