Overloaded record fields
Simon Peyton-Jones
simonpj at microsoft.com
Mon Jun 24 10:30:30 CEST 2013
| 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
More information about the Glasgow-haskell-users
mailing list