About Feature status for GHC 8.0

[Simon Peyton Jones]

  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:george.karachalias at gmail.com]
Sent: 18 November 2015 19:49
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Tom Schrijvers <tom.schrijvers at cs.kuleuven.be>; Dimitrios Vytiniotis <dimitris at microsoft.com>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151119/32cf5826/attachment-0001.html>