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


Ignore:
Timestamp:
Aug 29, 2013 8:16:22 AM (2 years 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.