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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users