Changes between Version 6 and Version 7 of Records/OverloadedRecordFields


Ignore:
Timestamp:
Dec 26, 2011 11:22:23 AM (4 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? ==