Overloaded record fields

[Barney Hilken]

This (AntC's points 1-8) is the best plan yet. By getting rid of dot notation, things
become more compatible with existing code. The only dodgy bit is import/export in point 7:

> 7. Implement -XPolyRecordFields, not quite per Plan.
>   This generates a poly-record field selector function:
> 
>       x :: r {x :: t} => r -> t    -- Has r "x" t => ...
>       x = getFld
> 
>    And means that H98 syntax still works:
> 
>       x e     -- we must know e's type to pick which instance
> 
>    But note that it must generate only one definition
>    for the whole module, even if x is declared in multiple data types.
>    (Or in both a declared and an imported.)
> 
>    But not per the Plan:
>    Do _not_ export the generated field selector functions.
>    (If an importing module wants field selectors,
>     it must set the extension, and generate them for imported data types.
>     Otherwise we risk name clash on the import.
>     This effectively blocks H98-style modules
>     from using the 'new' record selectors, I fear.)
>    Or perhaps I mean that the importing module could choose
>    whether to bring in the field selector function??
>    Or perhaps we export/import-control the selector function
>    separately to the record and field name???

I don't see the problem with H98 name clash. A field declared in a -XPolyRecordFields
module is just a polymorphic function; of course you can't use it in record syntax in a
-XNoPolyRecordFields module, but you can still use it.

I think a -XPolyRecordFields module should automatically hide all imported H98 field names and
generate one Has instance per name on import. That way you could import two clashing H98
modules and the clash would be resolved automatically.

Barney.