Overloaded record fields

[Adam Gundry]

Thanks everyone for the illuminating discussion, and for your awareness
of the dangers of bikeshedding. ;-) I think we are making progress though.

I like the idea of making -XFunnyDotSyntax or whatever a separate
extension. It's simple, resolves something of a love-hate issue, and
reduces backwards incompatibility for people who want overloaded record
fields in their existing code. Perhaps we can leave the arguments over
dot syntax for another thread?

There are a bunch of options for translating record fields into selector
functions:
 * monomorphically, as in Haskell 98, which is simple and robust but
doesn't allow overloading;
 * polymorphically, with Has, which permits overloading and is often the
'right' thing (but not always: it isn't great for higher-rank fields,
and can result in too much ambiguity);
 * do nothing in GHC itself, so the namespace is left open for lens or
another library to do wonderful things.

Rather than committing to one of these options, let's allow all of them.
If we start thinking of modules as importing/exporting *field names*,
rather than *selector functions*, perhaps we can allow each module to
decide for itself (via appropriate extensions) how it wants to bring
them in to scope.

I'll see what Simon thinks, draft an updated Plan, and continue trying
to understand what this will mean for GHC's Glorious Renamer...

Adam


On 27/06/13 14:10, Barney Hilken wrote:
> 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.
> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>