1. Shall I assume that we will be part of GHC 8.0? Dropping the literals from the pattern syntax is not an option at the moment since I am as swamped as ever. Nevertheless I can sprint for about a week and wrap what we have up which works OK. Yes: provided it all validates, just commit it. It’s already a substantial improvement over what we have right now.
I’d still like to understand why putting literals in guards rather than in patterns makes performance worse. But that should not stand in the way of getting it in. Still I hope you won’t drop the investigation altogether. I suspect that making literals-in-guards work acceptably well will improve performance all round. 1. Ben asked the developers to put the patches on the phabricator but you have told me that there is no need since you have reviewed the code yourself. Shall I assume this still holds? Yes I think so. Simon From: George Karachalias [mailto:[email protected]] Sent: 18 November 2015 19:49 To: Simon Peyton Jones <[email protected]> Cc: Tom Schrijvers <[email protected]>; Dimitrios Vytiniotis <[email protected]> Subject: About Feature status for GHC 8.0 Hello Simon, I got the mail from Ben Gamari about the state of our patch (since GHC 8.0 release is approaching) and I would like to respond to Ben tomorrow about it. Current State As you have probably noticed, I reverted back to the last commit (just revert, I did not rewrite history) that was able to bootstrap the compiler. This means that literals are currently in the pattern syntax. I could not find why moving literals to the solver generated so many problems. The only thing that I didn't have the time to address yet is warnings for data families but the deadline is close so I will look into that. Performance of current implementation When I started the implementation, I branched on this commit (it was the HEAD at the time): https://git.haskell.org/ghc.git/commit/b14dae3cc43572a9dd5ca11241981105e4281aac<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit.haskell.org%2fghc.git%2fcommit%2fb14dae3cc43572a9dd5ca11241981105e4281aac&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cc7a8decdcb624567aec908d2f0514579%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=WbpEsxtJAS0VJ7AWn44MxqxbFv6b4hQGOv4HJ2snfBM%3d> For some time now I was under the impression that our checker consumes a lot of memory because we had many perf-failures from the test suit. Yet, I ran the test suite with the above version of GHC. The performance tests from the test suite that fail for our implementation fail for that as well. Hence, I do not think that it is our problem exactly, I expect GHC's current HEAD to perform OK, and when merging I do not expect any performance problems from our checker (the only performance test we fail is testsuite/tests/perf/compiler/T5642.hs which has pattern matching on ~100 constructors and also nested pattern matching so I think that it makes a lot of sense to consume more memory on this one). More importantly, what should my response to Ben be? Many users are expecting the new checker so I would like to merge what we have when I finish the data families handling. I would like to drop the literals from patterns but for now I think that having the improved checker in GHC 8.0 is more important. We can always make it more generic in the future. To wrap things up: 1. Shall I assume that we will be part of GHC 8.0? Dropping the literals from the pattern syntax is not an option at the moment since I am as swamped as ever. Nevertheless I can sprint for about a week and wrap what we have up which works OK. 2. Ben asked the developers to put the patches on the phabricator but you have told me that there is no need since you have reviewed the code yourself. Shall I assume this still holds? George -- things you own end up owning you
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
