Changes between Version 34 and Version 35 of Records/OverloadedRecordFields/Implementation


Ignore:
Timestamp:
Aug 12, 2013 10:15:29 AM (2 years ago)
Author:
adamgundry
Comment:

qualified names

Legend:

Unmodified
Added
Removed
Modified
  • Records/OverloadedRecordFields/Implementation

    v34 v35  
    190190
    191191
     192== Qualified names ==
     193
     194Consider the following:
     195
     196{{{
     197module M where
     198  data S = MkS { foo :: Int }
     199
     200module N where
     201  data T = MkT { foo :: Int }
     202  data U = MkU { foo :: Int }
     203
     204module O where
     205  import M
     206  import N
     207
     208  f x = M.foo x
     209  g x = N.foo x
     210  h x = foo x
     211}}}
     212
     213Should 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:
     214
     215* Treat qualified and unqualified fields identically, but issue a warning for qualified fields
     216* Forbid referring to overloaded fields with qualified names (so `M.foo` and `N.foo` yield errors)
     217* 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)
     218
     219Of course, it is fine to use a qualified name in a record update.
     220
    192221== Outstanding bugs ==
    193222
     
    220249* Sort out GADT record updates.
    221250* Sort out data families with duplicated fields.
    222 * Fix the interaction between fields and qualified names: a qualified name can be used for unambiguous identification of fields (e.g. in updates) but should not be used as an overloaded variable.
     251* Sort out qualified names.
    223252* Improve error messages from typechecker:
    224253  * Unsolved `Accessor p f` where `p` is something silly