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


Ignore:
Timestamp:
Aug 12, 2013 10:15:29 AM (19 months 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