Changes between Version 54 and Version 55 of Records/OverloadedRecordFields/Implementation


Ignore:
Timestamp:
Aug 29, 2013 8:16:22 AM (11 months ago)
Author:
adamgundry
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Records/OverloadedRecordFields/Implementation

    v54 v55  
    122122Since the instances are not in scope in the usual way, `matchClassInst` and `tcLookupFamInst` look for the relevant constraints or type families and find the instances directly, rather than consulting `tcg_inst_env` or `tcg_fam_inst_env`. They first perform a lookup to check that the field name is in scope. A new field `tcg_fld_inst_env` in `TcGblEnv` maps a selector name in the current module to its `DFunId`s and `FamInst`s; this is needed for solving constraints that arise while checking the automatically generated instances themselves. 
    123123 
    124 '''AMG''' The instance lookup is currently implemented as a separate check, but needs to be integrated with the existing code to properly handle some obscure cases. 
     124'''AMG''' The instance lookup is currently implemented as a separate check, which means virtual fields should be forbidden. Perhaps it could be integrated into the existing overlapping instances mechanism, but type families need some care to avoid soundness bugs. 
    125125 
    126126 
     
    144144}}} 
    145145 
    146 Now, do we expect to report the 'x' in S(x) import as unused?  Actually the entire 'import B' is unused.  Only the typechecker will eventually know that.  But I think the type checker does actually record which instances are used, so perhaps we can make use of that info to give accurate unused-import info. 
    147  
    148 '''AMG''' I thought this would be the `tcg_ev_binds` field of the `TcGblEnv`, but this seems to be empty by the end of `tcRnModule`. We could also look at the `inert_solved_dicts` field of `InertSet`, but I'm not sure how to propagate the required information out of the `TcS` monad to the `TcM` monad where unused names are reported. 
     146Now, do we expect to report the 'x' in S(x) import as unused?  Actually the entire 'import B' is unused.  Only the typechecker will eventually know that. 
     147 
     148'''AMG''' How can we get this information out of the typechecker? 
    149149 
    150150 
     
    200200 
    201201 
    202 == Type-changing update: phantom arguments == 
    203  
    204 Consider the datatype 
    205  
    206 {{{ 
    207 data T a = MkT { foo :: Int } 
    208 }}} 
    209  
    210 where `a` is a phantom type argument (it does not occur in the type of `foo`). The traditional update syntax can change the phantom argument, for example if `r :: T Int` then `r { foo = 3 } :: T Bool` typechecks. However, `setField` cannot do so, because this is illegal: 
    211  
    212 {{{ 
    213 type instance SetResult (T a) "foo" Int = T b 
    214 }}} 
    215  
    216 Note that the result of the type family involves an unbound variable `b`.  
    217  
    218 In general, a use of `setField` can only change type variables that occur in the field type being updated, and do not occur in any of the other fields' types. 
    219  
    220  
    221202== Data families == 
    222203 
     
    239220 
    240221For the moment, I've simply disallowed duplicate fields for a single data family in a single module. It's fine to duplicate fields between different data families or across different modules, however. 
    241  
    242  
    243 == Qualified names == 
    244  
    245 Consider the following: 
    246  
    247 {{{ 
    248 module M where 
    249   data S = MkS { foo :: Int } 
    250  
    251 module N where 
    252   data T = MkT { foo :: Int } 
    253   data U = MkU { foo :: Int } 
    254  
    255 module O where 
    256   import M 
    257   import N 
    258  
    259   f x = M.foo x 
    260   g x = N.foo x 
    261   h x = foo x 
    262 }}} 
    263  
    264 Should there be a difference between `f`, `g` and `h`? It would seem odd if `f` could turn out to use the `foo` from `T` or `U` even though it explicitly says `M.foo`. I can see three sensible options: 
    265  
    266 * Treat qualified and unqualified fields identically, but issue a warning for qualified fields 
    267 * Forbid referring to overloaded fields with qualified names (so `M.foo` and `N.foo` yield errors) 
    268 * Treat a qualified name as a non-overloaded field, generating an ambiguity error if necessary (so `M.foo` is okay but `N.foo` is ambiguous) 
    269  
    270 Of course, it is fine to use a qualified name in a record update. 
    271  
    272 For now we've decided on the third option, allowing qualified names to refer only to a single field. 
    273222 
    274223 
     
    283232== Outstanding bugs == 
    284233 
    285 * typechecker/should_fail/tcfail102 (changed error message)  
     234* typechecker/should_fail/tcfail102 (changed error message) 
     235* Use of `PolyKinds` leads to `Upd` and `SetResult` instances that don't typecheck. 
    286236 
    287237 
     
    290240* With fundep in class, we don't need it in the instance. 
    291241* When there is only one thing in scope, don't do make it polymorphic (but document trade-offs). But maybe it should still support lenses? 
    292 * Forbid ambiguous qualified overloaded fields. 
    293242* Add `HsVarOut RdrName id` instead of `HsSingleRecFld` (or perhaps rename `HsVar` to `HsVarIn`); also useful to recall how the user referred to something. 
    294243 
     244* Support virtual fields or forbid them. 
    295245* Sort out reporting of unused imports. 
    296246* Haddock prints selector names in index and LaTeX exports list.