Overloaded record fields

[Simon Peyton-Jones]

| I am implementing an overloaded record fields extension for GHC as a
| GSoC project. Thanks to all those who gave their feedback on the
| original proposal! I've started to document the plan on the GHC wiki:
| 
| http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/
| Plan
| 
| If you have any comments on the proposed changes, or anything is unclear
| about the design, I'd like to hear from you

By way of context, there have been a succession of "adding-records-to-Haskell" debates which have failed to reach consensus. That's not because people are awkward.  Rather it's a complex design space with no global maximum; and because a clean-slate design (even if we were sure of a good one, which we aren't) would lack backward compatibility.

I have also had the sense of "I wish GHC HQ would just cut to the chase and decide *something*, even if not everyone thinks it's ideal".

So that's what this proposal is intended to do:

 * It is the smallest increment I can come up with that
   meaningfully addresses the #1 pain point (the inability to
   re-use the same field name in different records).

 * It is backward-compatible.

It does not do everything -- far from it -- leaving the field open for experimentation with more far-reaching designs.

The hope is that it offers a good power-to-weight ratio.  Do comment.  In particular, if you think it does *not* address the pain points, and hence offers weight but not power, please say so.  Tweaks to improve the design are also most welcome.  (Completely new designs less so; that's what we've been exploring over the last year or five.)

Thanks!

Simon