OverloadedRecordFields request for review
Hi devs, I just wanted to draw your attention to the OverloadedRecordFields proposal [1], which I've just updated and now has a corresponding implementation ready for review on Phab [2]. I'd very much appreciate any feedback on either the design or implementation. Thanks, Adam [1] https://github.com/ghc-proposals/ghc-proposals/pull/6 [2] https://phabricator.haskell.org/D2708 -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Status of OverloadedRecordFields [Was: Re: Proposal: Dot as Postfix Function Apply]
[copying ghc-devs as the following is perhaps more relevant there] On 04/11/15 10:44, Jeremy wrote: > Dot as Postfix Function Apply > (https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/DotPostfix) > was originally part of ORF, but dropped to keep the scope/discussion more > manageable. Now that ORF is in for GHC 8.0, I would like to re-propose dot > postfix syntax. I'm going to stay out of the discussion over the proposed syntax extension, but I feel like I should do some expectation management about ORF in GHC 8.0. As the wiki page [1] makes clear, ORF has been divided into three components, and so far only one of these is in GHC HEAD. The first part is a language extension, DuplicateRecordFields, which allows field names to be duplicated provided they are unambiguous. (It does not allow any kind of polymorphism over record fields.) This is already in HEAD. The second part is another language extension, OverloadedLabels, which introduces a new syntax #x for an identifier whose type is inferred and may depend on the text of the identifier. This is implemented and up on Phabricator [2], but not yet in HEAD. It should make GHC 8.0, but I'm wary about giving cast-iron guarantees. The third part, which is necessary for the OverloadedLabels syntax to be used for polymorphism over record fields, involves typeclass constraints that capture when a type has a particular field, with the instances provided automatically by GHC. This is not yet implemented in the intended form, and is unlikely to make GHC 8.0 (barring me having a sudden outbreak of free time...). Adam [1] https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields [2] https://phabricator.haskell.org/D1331 -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: OverloadedRecordFields merge
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 fuuze...@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@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
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 aus...@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 fuuze...@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@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/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
OverloadedRecordFields merge
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 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: OverloadedRecordFields merge
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
Re: OverloadedRecordFields
Hi folks, Apropos of nothing, I will be talking about OverloadedRecordFields in London on Monday 28th April at 6:30pm: https://skillsmatter.com/meetups/6345-overloaded-record-fields-for-haskell I've updated my OverloadedRecordFields branches to HEAD as of today. Validate on linux x86_64 is currently failing with a few perf failures, but several appear to be intermittently present on master (see below for details). How worried should I be about these? I'd like to get this reviewed/merged as soon as possible because the changes are quite wide-ranging so they tend to bitrot quickly. The code is in the following three repositories: https://github.com/adamgundry/ghc https://github.com/adamgundry/packages-base https://github.com/adamgundry/haddock The overloaded-record-fields branches have the history (rather messy, I'm afraid) and the orf-squashed branches have everything squashed into one commit per branch. More general information is on the wiki: https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields Cheers, Adam The perf failures on my branch are: perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T5030 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) Those on master are: perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/haddock haddock.Cabal [stat not good enough] (normal) Details of failures on my branch: = haddock.base(normal) 201 of 3977 [0, 0, 0] bytes allocated value is too high: Expectedbytes allocated: 7128342344 +/-5% Lower bound bytes allocated: 6771925226 Upper bound bytes allocated: 7484759462 Actual bytes allocated: 7638726640 *** unexpected failure for haddock.base(normal) = haddock.Cabal(normal) 202 of 3977 [0, 1, 0] max_bytes_used value is too high: Expectedmax_bytes_used: 95356616 +/-15% Lower bound max_bytes_used: 81053123 Upper bound max_bytes_used: 109660109 Actual max_bytes_used: 131046008 peak_megabytes_allocated value is too high: Expectedpeak_megabytes_allocated: 278 +/-10% Lower bound peak_megabytes_allocated: 250 Upper bound peak_megabytes_allocated: 306 Actual peak_megabytes_allocated: 326 bytes allocated value is too high: Expectedbytes allocated: 3979151552 +/-5% Lower bound bytes allocated: 3780193974 Upper bound bytes allocated: 4178109130 Actual bytes allocated: 4752508984 *** unexpected failure for haddock.Cabal(normal) = haddock.compiler(normal) 203 of 3977 [0, 2, 0] bytes allocated value is too high: Expectedbytes allocated: 28708374824 +/-10% Lower bound bytes allocated: 25837537341 Upper bound bytes allocated: 31579212307 Actual bytes allocated: 32010912664 *** unexpected failure for haddock.compiler(normal) = T1969(normal) 204 of 3977 [0, 3, 0] cd ./perf/compiler '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T1969.hs +RTS -V0 -tT1969.comp.stats --machine-readable -RTS -dcore-lint -static T1969.comp.stderr 21 max_bytes_used value is too high: Expectedmax_bytes_used: 1100 +/-20% Lower bound max_bytes_used: 880 Upper bound max_bytes_used: 1320 Actual max_bytes_used: 13787248 *** unexpected failure for T1969(normal) = T3064(normal) 207 of 3977 [0, 4, 0] cd ./perf/compiler '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3064.hs +RTS -V0 -tT3064.comp.stats --machine-readable -RTS T3064.comp.stderr 21 bytes allocated value is too high: Expectedbytes allocated: 308422280 +/-5% Lower bound bytes allocated: 293001166 Upper bound bytes allocated: 323843394 Actual bytes allocated: 351270952 *** unexpected failure for T3064(normal) = T5030(normal) 209 of 3977 [0, 5, 0] cd ./perf/compiler '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T5030.hs -fcontext-stack=300 +RTS -V0 -tT5030.comp.stats --machine-readable -RTS T5030.comp.stderr 21 = T5631(normal) 210 of 3977 [0, 5, 0] cd ./perf/compiler '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug
RE: OverloadedRecordFields
Adam I'm very happy to hear that... good stuff. I'm under water with ICFP submissions (deadline Sat). Moreover I think it is clearly too later to put this into 7.8; RC1 is out and I expect RC2 any day. So I suggest we plan to merge after 7.8 is out. Are the wiki pages up to date? Records/OverloadedRecordFields Records/OverloadedRecordFields/Implementation Records/OverloadedRecordFields/Plan The first does not point to the latter two; Plan may mean Design... I feel some rationalisation may make sense Simon | -Original Message- | From: Adam Gundry [mailto:a...@well-typed.com] | Sent: 24 February 2014 08:37 | To: Simon Peyton Jones | Subject: Re: OverloadedRecordFields | | Hi Simon, | | My OverloadedRecordFields branches[1,2,3] are up to date with HEAD as of | last Saturday. Validate on linux x86_64 reports only one failure, the | haddock.Cabal perf test, which might well be due to my Haddock changes, | and I will investigate. I'm not sure how to run the Haddock test suite? | | I am keen to get the code reviewed and into HEAD as soon as is | convenient, but I'm aware these are substantial changes, and don't want | to rush things. In particular, I would understand if you'd rather hold | them back until after the 7.8 final release. | | How would you like to proceed? | | Adam | | [1] https://github.com/adamgundry/ghc | [2] https://github.com/adamgundry/packages-base | [3] https://github.com/adamgundry/haddock | | | On 17/01/14 10:55, Simon Peyton Jones wrote: | Yes that sounds ok, thanks. I'd prefer to have a write-up of what | goes wrong with the 2-parameter story, so that we don't forget. | | Simon | | | -Original Message- | | From: Adam Gundry [mailto:a...@well-typed.com] | | Sent: 17 January 2014 10:15 | | To: Simon Peyton Jones | | Subject: OverloadedRecordFields | | | | Hi Simon, | | | | I'm conscious that things have gone off the boil a little wrt | | OverloadedRecordFields, partially as a consequence of the delayed | | 7.8 release but also my lack of time for other projects since | | starting work for Well-Typed. With that in mind, I'd like to propose | | a plan to get back on track: | | | | 1. Revert to the three-parameter story, where we have | | | | t ~ FldTy r f = Has r f t | | | | rather than | | | | Has r f. | | | | The two-parameter version generates significantly worse error | | messages, and there are some other unresolved problems, so I'm not | | sure it is worth the minor simplification. | | | | 2. Roll back some of the refactoring that I've struggled to get | | right (in particular, trying to make the generated FldTy/UpdTy | | axioms implicitTyThings). We can always revisit this in the future | though. | | | | 3. Merge HEAD into my branch: I suspect this will be a bit painful | | by now, but presumably with 7.8 imminent there won't be many major | | changes coming for a while? | | | | 4. Review the proposed changes with you and fix any show-stopping | | problems. | | | | 5. Merge into HEAD after 7.8 is released. | | | | Does this sound plausible? I'm happy to Skype if you like. | | | | Cheers, | | | | Adam | | | | P.S. I'm not sure if Andrew Kennedy has mentioned it to you, but | | Neil Ghani has got me some funding to work with them both on units | | of measure for Haskell. We are still sorting out the details, but I | | hope it might be possible to work on some kind of plugin mechanism | | for GHC's constraint solver, along the lines that Iavor has been | | investigating, if that would be of interest? | | | | -- | | Adam Gundry, Haskell Consultant | | Well-Typed LLP, http://www.well-typed.com/ | | | | -- | Adam Gundry, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: OverloadedRecordFields
Simon, On 25/02/14 16:18, Simon Peyton Jones wrote: I'm very happy to hear that... good stuff. I'm under water with ICFP submissions (deadline Sat). Moreover I think it is clearly too later to put this into 7.8; RC1 is out and I expect RC2 any day. So I suggest we plan to merge after 7.8 is out. Right. I wasn't suggesting to put OverloadedRecordFields in 7.8, just the 7.9 master branch! But given the potential need to backport fixes from master to the 7.8 branch, I think it makes sense to wait. Are the wiki pages up to date? Records/OverloadedRecordFields Records/OverloadedRecordFields/Implementation Records/OverloadedRecordFields/Plan The first does not point to the latter two; Plan may mean Design... I feel some rationalisation may make sense They are up to date but I'll go over them and tidy them up. Alas, it doesn't look like Trac supports redirects... Adam | -Original Message- | From: Adam Gundry [mailto:a...@well-typed.com] | Sent: 24 February 2014 08:37 | To: Simon Peyton Jones | Subject: Re: OverloadedRecordFields | | Hi Simon, | | My OverloadedRecordFields branches[1,2,3] are up to date with HEAD as of | last Saturday. Validate on linux x86_64 reports only one failure, the | haddock.Cabal perf test, which might well be due to my Haddock changes, | and I will investigate. I'm not sure how to run the Haddock test suite? | | I am keen to get the code reviewed and into HEAD as soon as is | convenient, but I'm aware these are substantial changes, and don't want | to rush things. In particular, I would understand if you'd rather hold | them back until after the 7.8 final release. | | How would you like to proceed? | | Adam | | [1] https://github.com/adamgundry/ghc | [2] https://github.com/adamgundry/packages-base | [3] https://github.com/adamgundry/haddock | | | On 17/01/14 10:55, Simon Peyton Jones wrote: | Yes that sounds ok, thanks. I'd prefer to have a write-up of what | goes wrong with the 2-parameter story, so that we don't forget. | | Simon | | | -Original Message- | | From: Adam Gundry [mailto:a...@well-typed.com] | | Sent: 17 January 2014 10:15 | | To: Simon Peyton Jones | | Subject: OverloadedRecordFields | | | | Hi Simon, | | | | I'm conscious that things have gone off the boil a little wrt | | OverloadedRecordFields, partially as a consequence of the delayed | | 7.8 release but also my lack of time for other projects since | | starting work for Well-Typed. With that in mind, I'd like to propose | | a plan to get back on track: | | | | 1. Revert to the three-parameter story, where we have | | | | t ~ FldTy r f = Has r f t | | | | rather than | | | | Has r f. | | | | The two-parameter version generates significantly worse error | | messages, and there are some other unresolved problems, so I'm not | | sure it is worth the minor simplification. | | | | 2. Roll back some of the refactoring that I've struggled to get | | right (in particular, trying to make the generated FldTy/UpdTy | | axioms implicitTyThings). We can always revisit this in the future | though. | | | | 3. Merge HEAD into my branch: I suspect this will be a bit painful | | by now, but presumably with 7.8 imminent there won't be many major | | changes coming for a while? | | | | 4. Review the proposed changes with you and fix any show-stopping | | problems. | | | | 5. Merge into HEAD after 7.8 is released. | | | | Does this sound plausible? I'm happy to Skype if you like. | | | | Cheers, | | | | Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: OverloadedRecordFields
On 25/02/14 16:18, Simon Peyton Jones wrote: Adam I'm very happy to hear that... good stuff. I'm under water with ICFP submissions (deadline Sat). Moreover I think it is clearly too later to put this into 7.8; RC1 is out and I expect RC2 any day. So I suggest we plan to merge after 7.8 is out. Are the wiki pages up to date? Records/OverloadedRecordFields Records/OverloadedRecordFields/Implementation Records/OverloadedRecordFields/Plan The first does not point to the latter two; Plan may mean Design... I feel some rationalisation may make sense Simon | -Original Message- | From: Adam Gundry [mailto:a...@well-typed.com] | Sent: 24 February 2014 08:37 | To: Simon Peyton Jones | Subject: Re: OverloadedRecordFields | | Hi Simon, | | My OverloadedRecordFields branches[1,2,3] are up to date with HEAD as of | last Saturday. Validate on linux x86_64 reports only one failure, the | haddock.Cabal perf test, which might well be due to my Haddock changes, | and I will investigate. I'm not sure how to run the Haddock test suite? Hi Adam, I'm seeing that perf failure even without any of your changes. Perhaps you could try validating without your changes to confirm that the perf failure happens anyway? There are two Haddock test-suites of interest: tests ran by GHC to make sure that appropriate files parse (I updated these just yesterday so please make sure you're up to date) and Haddock's own test-suite to make sure that the output we produce is correct. To run Haddock's own tests, you can use ‘cabal test’. You'll need QuickCheck and hspec for this. Alternatively, to only run the tests ensuring our XHtml output is as expected, you can run ‘cabal test html-test’. This skips the comment parser tests (which shouldn't be relevant to you) but also doesn't force you to install the test dependencies I mentioned. I haven't checked your branch yet but I ask that you add appropriate test cases in html-test. See the README in the directory for help. You might want to check the accept.lhs file to help you doing this. Lastly, note that we have been pushed something into Haddock every day since Saturday so make sure you're up to date. I'll also be pushing something today I think. Thanks | | I am keen to get the code reviewed and into HEAD as soon as is | convenient, but I'm aware these are substantial changes, and don't want | to rush things. In particular, I would understand if you'd rather hold | them back until after the 7.8 final release. | | How would you like to proceed? | | Adam | | [1] https://github.com/adamgundry/ghc | [2] https://github.com/adamgundry/packages-base | [3] https://github.com/adamgundry/haddock | | | On 17/01/14 10:55, Simon Peyton Jones wrote: | Yes that sounds ok, thanks. I'd prefer to have a write-up of what | goes wrong with the 2-parameter story, so that we don't forget. | | Simon | | | -Original Message- | | From: Adam Gundry [mailto:a...@well-typed.com] | | Sent: 17 January 2014 10:15 | | To: Simon Peyton Jones | | Subject: OverloadedRecordFields | | | | Hi Simon, | | | | I'm conscious that things have gone off the boil a little wrt | | OverloadedRecordFields, partially as a consequence of the delayed | | 7.8 release but also my lack of time for other projects since | | starting work for Well-Typed. With that in mind, I'd like to propose | | a plan to get back on track: | | | | 1. Revert to the three-parameter story, where we have | | | | t ~ FldTy r f = Has r f t | | | | rather than | | | | Has r f. | | | | The two-parameter version generates significantly worse error | | messages, and there are some other unresolved problems, so I'm not | | sure it is worth the minor simplification. | | | | 2. Roll back some of the refactoring that I've struggled to get | | right (in particular, trying to make the generated FldTy/UpdTy | | axioms implicitTyThings). We can always revisit this in the future | though. | | | | 3. Merge HEAD into my branch: I suspect this will be a bit painful | | by now, but presumably with 7.8 imminent there won't be many major | | changes coming for a while? | | | | 4. Review the proposed changes with you and fix any show-stopping | | problems. | | | | 5. Merge into HEAD after 7.8 is released. | | | | Does this sound plausible? I'm happy to Skype if you like. | | | | Cheers, | | | | Adam | | | | P.S. I'm not sure if Andrew Kennedy has mentioned it to you, but | | Neil Ghani has got me some funding to work with them both on units | | of measure for Haskell. We are still sorting out the details, but I | | hope it might be possible to work on some kind of plugin mechanism | | for GHC's constraint solver, along the lines that Iavor has been | | investigating, if that would be of interest? | | | | -- | | Adam Gundry, Haskell Consultant | | Well-Typed LLP, http
Re: OverloadedRecordFields
On 2014-02-25 at 18:42:03 +0100, Adam Gundry wrote: [...] They are up to date but I'll go over them and tidy them up. Alas, it doesn't look like Trac supports redirects... actually, it does, but the plugin was just missing; see https://ghc.haskell.org/trac/ghc/wiki/WikiMacros#Description for more details ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: OverloadedRecordFields status update
On 09/09/13 16:53, Gabor Greif wrote: On 9/9/13, Adam Gundry adam.gun...@strath.ac.uk wrote: On 06/09/13 17:45, Gabor Greif wrote: On 9/5/13, Adam Gundry adam.gun...@strath.ac.uk wrote: I have been working on a new extension, OverloadedRecordFields, and it is now essentially feature-complete. Unfortunately, I doubt it will make it into 7.8, as the changes are quite extensive, but I hope to get it in HEAD soon thereafter. That would be great, it appears to be a great example of -XConstraintKinds, too! It relies quite heavily on type-level strings (-XDataKinds), if that's what you mean? No, I mean ConstraintKinds, I assume all the Has* constraints have kind 'Constraint' ? (I strongly assume so). Ah, I see your point. Yes, the kind of `Has` is * - Symbol - * - Constraint although it is actually implemented as a typeclass in the base library, so in this respect it's not particularly special. (Instances of the typeclass are automatically generated and cannot be given in the normal way, however.) Cheers, Adam ... ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: OverloadedRecordFields status update
On 9/9/13, Adam Gundry adam.gun...@strath.ac.uk wrote: On 06/09/13 17:45, Gabor Greif wrote: On 9/5/13, Adam Gundry adam.gun...@strath.ac.uk wrote: I have been working on a new extension, OverloadedRecordFields, and it is now essentially feature-complete. Unfortunately, I doubt it will make it into 7.8, as the changes are quite extensive, but I hope to get it in HEAD soon thereafter. That would be great, it appears to be a great example of -XConstraintKinds, too! It relies quite heavily on type-level strings (-XDataKinds), if that's what you mean? No, I mean ConstraintKinds, I assume all the Has* constraints have kind 'Constraint' ? (I strongly assume so). I would really appreciate comments on the design [1], for which there is How would such a feature interact with http://hackage.haskell.org/package/vinyl ? The short answer is that it shouldn't. Vinyl (which I wasn't aware of before now, thanks for the pointer!) basically replaces the Haskell records system wholesale, making records entirely separate from data declarations, and turning fields into first-class objects. This should peaceably coexist with -XOverloadedRecordFields but I don't see a way to integrate the two. Okay. Thanks for the answers, Gabor Adam Gabor a prototype implementation [2] that works in GHC 7.6.3. If you'd like to review the code, you can check out the overloaded-record-fields branch from the Github repositories [3, 4], and there are notes on the implementation on the wiki [5]. Thanks! Adam [1] http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan [2] https://github.com/adamgundry/records-prototype [3] https://github.com/adamgundry/ghc [4] https://github.com/adamgundry/packages-base [5] http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Implementation ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: OverloadedRecordFields status update
On 06/09/13 17:45, Gabor Greif wrote: On 9/5/13, Adam Gundry adam.gun...@strath.ac.uk wrote: I have been working on a new extension, OverloadedRecordFields, and it is now essentially feature-complete. Unfortunately, I doubt it will make it into 7.8, as the changes are quite extensive, but I hope to get it in HEAD soon thereafter. That would be great, it appears to be a great example of -XConstraintKinds, too! It relies quite heavily on type-level strings (-XDataKinds), if that's what you mean? I would really appreciate comments on the design [1], for which there is How would such a feature interact with http://hackage.haskell.org/package/vinyl ? The short answer is that it shouldn't. Vinyl (which I wasn't aware of before now, thanks for the pointer!) basically replaces the Haskell records system wholesale, making records entirely separate from data declarations, and turning fields into first-class objects. This should peaceably coexist with -XOverloadedRecordFields but I don't see a way to integrate the two. Adam Gabor a prototype implementation [2] that works in GHC 7.6.3. If you'd like to review the code, you can check out the overloaded-record-fields branch from the Github repositories [3, 4], and there are notes on the implementation on the wiki [5]. Thanks! Adam [1] http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan [2] https://github.com/adamgundry/records-prototype [3] https://github.com/adamgundry/ghc [4] https://github.com/adamgundry/packages-base [5] http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Implementation ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: OverloadedRecordFields status update
On 9/5/13, Adam Gundry adam.gun...@strath.ac.uk wrote: Hi ghc-devs, I have been working on a new extension, OverloadedRecordFields, and it is now essentially feature-complete. Unfortunately, I doubt it will make it into 7.8, as the changes are quite extensive, but I hope to get it in HEAD soon thereafter. That would be great, it appears to be a great example of -XConstraintKinds, too! I would really appreciate comments on the design [1], for which there is How would such a feature interact with http://hackage.haskell.org/package/vinyl ? Gabor a prototype implementation [2] that works in GHC 7.6.3. If you'd like to review the code, you can check out the overloaded-record-fields branch from the Github repositories [3, 4], and there are notes on the implementation on the wiki [5]. Thanks! Adam [1] http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan [2] https://github.com/adamgundry/records-prototype [3] https://github.com/adamgundry/ghc [4] https://github.com/adamgundry/packages-base [5] http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Implementation ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
