Changes between Version 6 and Version 7 of Records/OverloadedRecordFields


Ignore:
Timestamp:
Dec 26, 2011 11:22:23 AM (2 years ago)
Author:
igloo
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Records/OverloadedRecordFields

    v6 v7  
    5454}}} 
    5555This seems clunky to me, and I don't really want to deal with this infinite family of classes (eg how are the brought into scope).  I see no disadvantages to a `String` parameter, which will form part of GHC's new kind system. 
     56 
     57== Scope control by generalising the `String` type in `Has` == 
     58 
     59The proposal above doesn't allow label names to be scoped: if one module internally uses `"field"` as a label name then another module can break the abstraction by using the same string `"field"`. 
     60 
     61We can fix this by instead of having 
     62{{{ 
     63class Has (r :: *) (f :: String)       (t :: *) where 
     64}}} 
     65having something like 
     66{{{ 
     67class Has (r :: *) (ft :: *) (f :: ft) (t :: *) where 
     68}}} 
     69(where `ft` stands for field type). 
     70 
     71The expression 
     72{{{ 
     73foo.field 
     74}}} 
     75(starting with a lowercase letter) would behave as described above, with `ft ~ String`. 
     76 
     77But 
     78{{{ 
     79foo.Field 
     80}}} 
     81(starting with an uppercase letter) would use the Field constructor that is in scope, e.g. if we had 
     82{{{ 
     83data FieldT = Field 
     84}}} 
     85then `ft ~ FieldT`. Then we can choose whether or not to export `FieldT(Field)`. 
    5686 
    5787== Should `get` have a proxy argument? ==