OverloadedRecordFields merge

[Austin Seipp]

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 <austin at well-typed.com> 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
> <fuuzetsu at fuuzetsu.co.uk> 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 at 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/