Overloaded record fields

[AntC]

> 
> ... the orthogonality is also an important benefit.
>  It could allow people like Edward and others who dislike ... 
>  to still use ...
> 

Folks, I'm keenly aware that GSoC has a limited timespan; and that there 
has already been much heat generated on the records debate.

Perhaps we could concentrate on giving Adam a 'plan of attack', and help 
resolving any difficulties he runs into. I suggest:

1. We postpone trying to use postfix dot:
   It's controversial.
   The syntax looks weird whichever way you cut it.
   It's sugar, whereas we'd rather get going on functionality.
   (This does mean I'm suggesting 'parking' Adam's/Simon's syntax, too.)

2. Implement class Has with method getFld, as per Plan.

3. Implement the Record field constraints new syntax, per Plan.

4. Implicitly generate Has instances for record decls, per Plan.
   Including generating for imported records, 
   even if they weren't declared with the extension.
   (Option (2) on-the-fly.)

5. Implement Record update, per Plan.

6. Support an extension to suppress generating field selector functions.
   This frees the namespace.
   (This is -XNoMonoRecordFields in the Plan,
    but Simon M said he didn't like the 'Mono' in that name.)
   Then lenses could do stuff (via TH?) with the name.

   [Those who've followed so far, will notice that
    I've not yet offered a way to select fields.
    Except with explicit getFld method.
    So this 'extension' is actually 'do nothing'.]

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???

    Taking 6. and 7. together means that for the same record decl:
    * one importing module could access it as a lens
    * another could use field selector functions

8. (If GSoC hasn't expired yet!)
   Implement ‑XDotPostfixFuncApply as an orthogonal extension ;-).

AntC