Re: Status update on overloaded records work?

Hi Johan, all, Thanks for the interest in OverloadedRecordFields! I've been meaning to write a blog post on the current status, but you've beaten me to it. The extension is essentially finished, modulo a few minor issues that I need to work through, and should hit HEAD soon after 7.8 is cut. That will give us time to experiment with the feature before it goes public in 7.10. As AntC says, the wiki has more detail on the design. I've just updated it with some recent tweaks (thanks to Edward and Simon brainstorming at ICFP). You can also try out the prototype (which works in 7.6.3): https://github.com/adamgundry/records-prototype/blob/master/RecordsPrototype... Adam On 16/10/13 07:19, Simon Peyton-Jones wrote:

Looping in Adam Gundry, who did the work!

Simon

| -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of AntC | Sent: 15 October 2013 22:42 | To: ghc-devs@haskell.org | Subject: Re: Status update on overloaded records work? | | > Johan Tibell writes: | > | > I'm curious about the current status of the overloaded records work. | | Hi Johan, I think Adam has documented as he's gone along: | http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Pla | n | (And that points to implementation notes.) | | I'll leave Adam/Simon to comment more fully, but from my point of view | as | an observer with some 'skin in the game' ... | | > Is the design the same as when the project started? | | No: | - Higher-Ranked types can't be supported | -- and SPJ's initial proposal put a lot of weight on them. | There's an easy (IMO) work-round; | but it does compromise backward compatibility. | + Type changing update _is_ supported (with limits) | I think that was a justified trade-off for H-R types. | + Adam has been able to support Lenses. | | - (What I was hoping for but didn't get.) | No compiler flag to suppress creating selector functions. | This would have allowed records to be declared re-using the same | name; | but left it entirely to the developer as to how to access them. | (I was trying to promote the TH and/or Lenses cottage industries.) | | > Did we manage to keep the types simple? | | I guess simplicity is in the eye of the beholder ;-) | For 'gettable' fields, the sugar is as per SPJ's suggestion. | There isn't sugar for updating. | | The un-sugared types are pretty gnarly. | I suspect that'll mean obscure and confusing error messages. | | | AntC

-- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/