Re: OverloadedRecordFields merge

Hello all, The work is now instead on the 'wip/orf' branch. In particular this is more in-line with what we traditionally do now. The new branch fixes an error - I forgot to add a file! It should now all build correctly. Finally, the Haddock changes are now correctly attributed to Adam (not me), and the interface file version was bumped to v26. Hopefully that should do it! On Tue, Apr 22, 2014 at 4:03 AM, Austin Seipp wrote:

I rebased the ORF work (fixing a minor merge by hand) and it is now available in GHC and Haddock under the 'orf' branches. Do feel free to give them a try.

On Mon, Apr 21, 2014 at 8:53 AM, Mateusz Kowalczyk wrote:

...

On 04/21/2014 03:12 PM, Austin Seipp wrote:

...

Hello all,

As some of you might have seen last week, my colleague Adam took the time to get his OverloadedRecordFields back up to date with regards to HEAD.

I'm now wondering: when should we pull the trigger? I am inclined to say 'soon'. In particular, the ORF changes are rather large, and Adam has hinted to me it touches a lot of components of e.g. name resolution. A large change with some fairly big impacts, in other words.

I think it is perhaps best to merge soon - so that it does not get out of date and cause undue burden to Adam, but also so that we have maximal amounts of time to sort out issues in the long haul that it might expose.

Simon - I believe you reviewed Adam's work in the past, yes? I am wondering what you think we should do here. I am more than willing to defer to you and let you do the merge after another review. On the other hand, if you already did review it and feel confident after a look or two, I'm more than willing to take over sometime this week.

Adam - since you emailed us last week, Herbert went ahead and merged 'base' into GHC's repository. This does not invalidate the changes you gave us, it just means the two commits can be collapsed into one. Also, the performance failures seem like minor anomalies, but I have not yet directly built the ORF branch to confirm this. You're free to rebase yourself, or I can likely handle it without much issue soon.

If anyone else has opinions here - please speak up, I'm all ears.

For those reading, Adam's implementation is available in current form here:

- https://github.com/adamgundry/ghc - https://github.com/adamgundry/packages-base - https://github.com/adamgundry/haddock

I see a change to the Haddock interface file but the interface file version was not bumped (top of the file) which means that Haddock will try to read old interface file versions which will fail (I think). I would try myself but my system currently isn't really in appropriate state, perhaps I manage to do so later. It'd be great if we could default that to empty Map if we can't read it in but I don't think we can do that with existing binary (but we should be able to with the future CBOR stuff).

Other than that, the Haddock patch looks good but again, I can not try it myself at the moment.

I have to say I'm quite excited for overloaded records.

-- Mateusz K. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards,

Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/