- ghc-devs - Haskell.org

Beta Performance dashboard
by Joachim Breitner 21 Jul '14

21 Jul '14

Hi, I guess it’s time to talk about this, especially as Richard just brought it up again... I felt that we were seriously lacking in our grip on performance issues. We don’t even know whether 6.8.3 was better or worse than 6.8.3 or 7.6.4 in terms of nofib, not to speak of the effect of each single commit. I want to change that, so I set up a benchmark monitoring dashboard. You can currently reach it at: http://ghcspeed-nomeata.rhcloud.com/ What does it do? ~~~~~~~~~~~~~~~~ It monitors the repository (master branch only) and builds each commit, complete with the test suite and nofib. The log is saved and analyzed, and some numbers are extracted: * The build time * The test suite summary numbers * Runtime (if >1s), allocations and binary sizes of the nofib benchmarks These are uploaded to the website above, which is powered by codespeed, a general performance dashboard, implemented in Python using Django. Under _Changes_, it provides a report for each commit (changes wrt. to the previous version, and wrt. to 10 revisions earlier, the so-called “trend”). A summary of these reports is visible on the front-page. The _Timeline_ is a graph for each individual performance number. If there are bumps, you can hopefully find them there! You can also compare to 7.8.3, which is available as a “baseline”. _Comparison_ will be more useful if we have more tagged revision, or if were benchmarking various options (e.g. -fllvm): Here you can do bar-chart comparisons. Why codespeed? ~~~~~~~~~~~~~~ For a long time I searched for a suitable software product, and one criterion is that it should be open source, rather simple to set up and mostly decoupled from other tools, i.e. something that I throw numbers at and which then displays them nicely. While I don’t think codespeed is the best performance dashboard out there (I find http://goperfd.appspot.com/perf a bit better; I wonder how well codespeed scales to even larger numbers of benchmarks and I wish it were more git-aware), it was the easiest to get started with. And thanks to the loose coupling of (1) running the tests to acquire a log, (2) parsing the log to get numbers and (3) putting them on a server, we can hopefully replace it when we come along something better. I was hoping for the Phabricator guys to have something in their tool suite, but doesn’t look like it. How does it work (currently)? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ My office PC is underused (I work on my laptop), so its currently dedicated to it. I have a simple shell script that monitors the repo for new versions. It builds the newest revision and works itself back to the commit where everything was turned into submodules: https://github.com/nomeata/codespeed/blob/ghc/tools/ghc/watch.sh It calls a script that does the actual building: https://github.com/nomeata/codespeed/blob/ghc/tools/ghc/run-speed.sh This produces a log file which should contain all the required numbers somewhere. A second script extracts these numbers (with help of nofib-analyze) and converts them into codespeed compatible JSON files: https://github.com/nomeata/codespeed/blob/ghc/tools/ghc/log2json.pl Finally, a simple invocation to curl uploads them to codespeed: https://github.com/nomeata/codespeed/blob/ghc/tools/ghc/upload.sh So if you want additional benchmarks to be tracked, make sure they are present in the logs and adjust log2json.pl. codespeed will automatically pick up new benchmarks in these logs. Reimplementations in Haskell are also welcome :-) The testsuite is run with VERBOSE=4, so the performance numbers are also shown for failing test cases. So once a test case goes over the limit, you can grep through previous logs try to find the real culprit. I uploaded the logs (so far) to https://github.com/nomeata/ghc-speed-logs (but this is not automated yet, ping me if you need an update on this). What next? ~~~~~~~~~~ Clearly, the current setup is only good enough to evaluate the system. Eventually, I might want to use my office PC again, and the free hosting on openshift is not very powerful. So if we want to keep this setup and make it “official”, we need find a permanent solution.¹ This involves: * A dedicated machine to run the benchmarks. This probably shouldn’t be a VM, if we want to keep the noise in the runtime down. * A machine to run the codespeed server. Can be a VM, or even run on any of the system that we have right now. Just needs a database (postgresql preferably) and a webserver supporting WSGI (i.e. any of them). * Maybe a better place to store the logs for public consumption. Also, there are way to improve the system: * As I said, I don’t think codespeed is the best. If we find something better, we can replace it. Since we have all the logs, we can easily fill the new system with the data, or even run both at the same time. * We might want to have more numbers. I am already putting lines-of-code and disk space usage numbers into the logs, but do not parse them yet. * In particular, we might want to put in each performance test case as a benchmark of its own, to easier find commits that degrade (or improve!) performance. I’m not sure how well the web page will handle that. * We might want to replace my rather simple watch.sh-script by something more serious. In particular, I imagine that our builder setup could manages this, with a dedicated builder doing the benchmark runs and the builder server scheduling a build for each commit. That’s it for now. Enjoy clicking around! Greetings, Joachim ¹ I guess that could be considered beta-reduction :-) -- Joachim Breitner e-Mail: mail(a)joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata(a)joachim-breitner.de

4 4

Multi-instance packages status report
by Edward Z. Yang 21 Jul '14

21 Jul '14

Hello all, As you may have noticed, I've been knocking around GHC and Cabal the past few weeks. One of the tasks that has been on my list is essentially reimplementing Philipp Schuster's 2012 GSoC, with a few small but important architectural differences. Here is a status report of what is going on. In my copy of GHC and Cabal [1,2], you can now install multiple copies of a package with differing dependencies to the package database, i.e. q-1.0 compiled against p-1.0, and against p-2.0. The packages in the database are distinguished via a *package key*, which is an md5 hash of the package id (e.g. q-1.0) and the sorted list of the package IDs of the transitive closure of dependencies (e.g. p-1.0 or p-2.0). The package key is used to generate linker symbols for packages, so it's possible to link together both copies of q in the same program, as long as you rename the modules appropriately (of course, the redefined types are considered unequal). When registering a package, ghc-pkg now checks and removes duplicate package keys, as opposed to package IDs. I've also implemented many of the necessary niceties for making it pleasant to deal with duplicated package IDs: for example, GHC's output logic has been adjusted to only qualify a package ID with the package key when there are multiples of the same package ID exposed in the database. I've also adjusted GHC's build system to use package keys rather than package IDs to refer to packages when building. Like the original GSoC project, we still need to have decisions on some of the major design choices. I think the most pressing one is "simplistic dependency resolution" when you use, e.g. ghc -package foo-1.0 or ./Setup configure --with-constraint="foo==1.0". Right now, I pick dependencies in an unspecified manner, check if they are consistent, and bail out if they are not. As it turns out, both GHC and ./Setup configure will already compute the transitive closure of dependencies, so I suspect we might be able to do something clever here. Less pressing but eventually necessary is clueing in cabal-install. Comments would be especially appreciated. Cheers, Edward [1] https://phabricator.haskell.org/D80 [2] https://github.com/haskell/cabal/pull/2002

2 1

Status updates
by Austin Seipp 21 Jul '14

21 Jul '14

Hello *, Here are some updates from this past week. - I sent an email earlier about 7.10.1 tickets - please vote on them! - Related to that - as I said last week, I finished remilestoning a lot of tickets, but more remain. Please excuse any mail spam, but do pay attention to your bugs if they change! - I cleaned up some tabs and whitespace in the compiler in low-activity areas. You may have seen the commits go by, but otherwise it shouldn't be a problem. I'll probably keep eliminating errors in low-contention areas of the codebase as I can. Ditto with 'arc lint'. - I've cleaned up a bunch of wiki pages relating to the git repositories, and submodule management, but more stuff remains. See below for my reply to Simon. - I've been lazy about the Applicative-Monad work, since some of it fell out of date. But now other work is pending on it, so it's time to finish it Real Soon Now. - I'm working out some of the kinks in the Phabricator automation for builds etc, but it's not quite done yet - sorry! Here are some things I plan to do this week, roughly in order of priority: - I'm going to keep cleaning up these Git pages to make them more sensible, since some of the information is still wrong. Please see the comments below this and let me know what's wrong! - I will finalize these Phabricator things, which I should be able to get done with soon. This is all mostly annoying HTTP endpoint and PHP/Python stuff and is a bit of a chore to test/setup completely. - I am going to spend time next on landing AMP and get it back into shape. Yes, really landing it; I need to send something upstream to Cabal still. - The patch queue on Trac needs to be drained and slipped my mind. - Given all that I'll also probably end up continuing to fix lint errors, and hopefully fix bugs based on what people want in 7.10. :) Below is a quick recap of what me and Simon discussed last week, mostly stuff from the above: > · Complete re-milestoning. Then email ghc-devs and ghc-users [send a draft to Simon & Simon first] > >o Giving links to suitable query(s) > >o Saying that any ticket that isn’t > >a) milestoned 7.8.4 or 7.10.1, and > >b) high or highest priority, > >isn’t going to get attended to by us. > >o Inviting them to bid (on the ticket) for high/highest 7.10.1 status, explaining why it is important to them. And that it’s more likely to be done if they help. I sent this mail earlier - please bid on 7.10.1 tickets! > · Trac/Phab integration Doing this in a complete manner is turning out to be a bit of work and I haven't gotten done yet with having comments appear on tickets just yet. My goal is to have it so that when you say 'arc diff', you can put the words: Trac: #9832, #9123 into the review, and it will auto appear on Phabricator as a custom field, hyperlink it, and then a comment will appear on Trac. I have to write some PHP and Python on both ends to get this all working, though. Also the builder script is currently really crappy, so I'm fixing that a bit, so it will correctly deal with concurrent builds and multiple builders. > · Document how to update a submodule; e.g. haddock > > o We worked through an example > > o We need a canonical place on the wiki to say which branch GHC should be tracking on the submodule; and how to check that it is > > o Need to talk to haddock and cabal folk about whether GHC should track master or a branch in their repo. They may want a more stable branch to work on. > > > · Wiki pages > > o Be sure to update https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources, to include simple cloning story > > o Consolidate “how to use Git” information into WorkingConventions/Git, perhaps headed “Git workflows”. Merging WorkingConventions/Git with the Git/Submodules page will make it intimidatingly long. > > § Think about how to split it up. > > § Tricks should be on a separate page. > > § Focus on tasks, not technology > > o wiki:Repositories page says where everything lives, but not how to use them. > > § Needs updating to have the correct data. > > § Also integrate https://ghc.haskell.org/trac/ghc/wiki/Repositories/Upstream This is now done with a first draft. I think I simplified the pages a lot. See here: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git and: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules I plan on obsoleting the old Repositories pages since they're mostly redundant and out of date now. There may be more info stuffed into other places, but I imagine it will stay under this hierarchy. There are still some links and prose that need to be rewritten that I obviously missed however. > · Merge AMP stuff. Should be done now. (Without join in Monad for now, #9123.) https://phabricator.haskell.org/D13 Unfortunately this is still pending a few things, so I haven't gotten it done yet. :( > o Maybe make the bug tracker page easier to find. > > § Move https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions from “Joining in” side-bar to “Documentation” and list it as “Working conventions” > > § Move newcomer material from wiki:WorkingConventions to wiki:Newcomers, and put *that* under “Joining in” > > Now the bug tracker stuff is in Working Conventions, easier to find. This has all been done. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

GHC 7.10.1 tickets
by Austin Seipp 21 Jul '14

21 Jul '14

Hello *, We need to be sorting out tickets for 7.10.1. Last week, I spent some time remilestoning things to get them into the rough correct places (roughly), but we all need some help to get an idea of what we should fix for the release. Here's a query to look at: https://ghc.haskell.org/trac/ghc/query?status=!closed&milestone=7.10.1&orde… I have already categorized these tickets roughly, but we'll probably still address some of the priorities on existing tickets of course. These are all of the 7.10.1 tickets currently, but there are some important things to note: 1) There are a lot of them! 2) Most of the development team is probably not going to pay attention to many of them unless they are high or highest priority in Trac. (That's just the result of having so many tickets for 7.10.1 at the moment.) So I'm asking if people out there with the time can help chip in and give some input on the ticket! - If there's a ticket that interests you, please comment on it! - Say why you think it should have its priority elevated for 7.10.1. - It will certainly be easier if you offer to help. Then we can move it upwards and we'll look at it. Finally, if you are *really* dedicated or a newcomer - please go through the tickets and see if any of them can be closed, reassigned, marked as duplicates, etc. There are certainly some dead tickets and probably easy tickets for newcomers, so just spend a few minutes looking if you're interested! (Otherwise they just end up getting punted off in batch modifications) Thanks! ~~~~~~~ BTW, for developers, you can look at your assigned tickets for 7.10.1 here, it's also always on the sidebar: https://ghc.haskell.org/trac/ghc/query?owner=%24USER&status=infoneeded&stat… -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Planning a Haskell Platfrom Release Candidate this weekend
by Mark Lentczner 21 Jul '14

21 Jul '14

Here's my remaining list before putting out a realse candidate. I'm aiming for this weekend: *-- General --* [ ] haddock linkage from HP packages to GHC core packages is broken [ ] decision on QuickCheck? *-- Source Tarball --* [ ] missing platform.sh scripts [ ] missing os-extras in hptool/src *-- Mac --* [ ] start.html needs a once over updating [ ] uninstall-hs should clean out /usr/local/bin symlinks (as it does with /usr/bin) *-- Windows --* [ ] GLUT issue in ghci *-- Website --* [ ] templatize info on pages [ ] add build mode to bptool Main - needs to take file of downloads & hashes Anyone have anything else? Otherwise... we're almost good to go!!!! - Mark

1 1

Re: Thread status constants
by Jost Berthold 19 Jul '14

19 Jul '14

> Message: 2 > Date: Sat, 19 Jul 2014 15:00:17 +1000 > From: Kyle Van Berendonck <kvanberendonck(a)gmail.com> > To: "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> > Subject: Thread status constants > Message-ID: > <CAFSvR6A3maSWngY%3DGJdATvGPjTAyuPokXZ5%3DrLtLT%3DEbYdSLKA(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > I found these: > https://github.com/ghc/ghc/blob/5f3c5384df59717ca8013c5df8d1f65692867825/in… > > They go only 0-14, so there's some long chains of branches and stuff in hot > paths that could be cleaned up into single &-masked branches by changing > these into a set of flags. > > And then I saw these: > https://github.com/ghc/ghc/blob/master/libraries/base/GHC/Conc/Sync.lhs#L483 > > Where does 16 and 17 come from -- I couldn't find them in the header files > anywhere? > > Kyle Hi Kyle, I had a look at these constants just recently. About 16 and 17, see here: https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm#L853 About the others:The block reasons received two updates just recently. Turns out that the eventlog (GHC's post-mortem tracing for threadscope et al.) expects these states to have particular values (those in includes/rts/Constants.h, consider them a fixed ABI for the time being). See here for the story: https://ghc.haskell.org/trac/ghc/ticket/9003 NB: Darn... base still uses GHC-7.8.2 constants. Thanks for the pointer! About your proposal to use bit masks: Did you find some of those hot paths? I believe (believe, unchecked...) that there are not too many places where a complete switch over all possible reasons is done (apart from debug output maybe); the typical use is rather to compare to one single constant than to all. So the performance might not increase too much from optimisations. Again, just a hunch, not verified. If the RTS contains code specialised to the current constants, these places need to be kept symbolic, to avoid future breakage when new states are added. A fix which removes the tight implicit dependency of ghc-events from the constants in includes/rts/Constants.h is pending, btw. / Jost

3 3

Re: Update Cabal submodule to HEAD (1.21)
by Joachim Breitner 19 Jul '14

19 Jul '14

Hi Edward, your commit makes the builders fail: [28 of 79] Compiling Distribution.Simple.Utils ( libraries/Cabal/Cabal/Distribution/Simple/Utils.hs, bootstrapping/Distribution/Simple/Utils.o ) libraries/Cabal/Cabal/Distribution/Simple/Utils.hs:382:46: `Process.delegate_ctlc' is not a (visible) constructor field name libraries/Cabal/Cabal/Distribution/Simple/Utils.hs:408:46: `Process.delegate_ctlc' is not a (visible) constructor field name make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1 make: *** [all] Error 2 https://s3.amazonaws.com/archive.travis-ci.org/jobs/30289010/log.txt Please fix! Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 1

Re: Windows breakage -- again
by Niklas Larsson 18 Jul '14

18 Jul '14

I get the same failure when I try to build HEAD. Turns out the error occurs on the 32-bit Windows build, and my successful build was a 64-bit build. My 64-bit build still succeeds. Also, gcc is 4.5.2 on 32-bit, not 4.6.3 as on 64-bit. Niklas 2014-07-16 14:48 GMT+02:00 Niklas Larsson <metaniklas(a)gmail.com>: > I have built ghc on windows after that was added with no issue. > > I can take a look this evening and see how HEAD works for me. > > The standard gcc in the tarballs is 4.6.3, which is getting long in the > tooth, there is an issue on trac to upgrade it. > > -- Niklas > > ------------------------------ > Från: Johan Tibell <johan.tibell(a)gmail.com> > Skickat: ‎2014-‎07-‎16 09:57 > Till: Simon Peyton Jones <simonpj(a)microsoft.com> > Kopia: ghc-devs(a)haskell.org > Ämne: Re: Windows breakage -- again > > You can rollback the commit (git revert 4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) > and push that to the repo if you wish. I will try to re-add the primop > again after I figure out what's wrong. > > > On Wed, Jul 16, 2014 at 9:37 AM, Johan Tibell <johan.tibell(a)gmail.com> > wrote: > >> I added some primops about a month ago >> (4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) that call __sync_fetch_and_add, >> a gcc/llvm builtin. I'm a bit surprised to see this error. The GCC manual >> [1] says: >> >> > " Not all operations are supported by all target processors. If a >> particular operation cannot be implemented on the target processor, a >> warning will be generated and a call an external function will be >> generated. The external function will carry the same name as the builtin, >> with an additional suffix `_n' where n is the size of the data type." >> >> I'm a bit surprised by this error for two reasons: >> >> * A call to that symbol should only be generated if the CPU doesn't >> support the atomic instructions. What CPU model does Windows report that >> you have? >> >> * gcc should define such a symbol. For me the following test program >> compiles: >> >> #include <stdint.h> >> >> uint8_t test(uint8_t* ptr, uint8_t val) { >> return __sync_fetch_and_add_1(ptr, val); >> } >> >> int main(void) { >> uint8_t n; >> return test(&n, 1); >> } >> >> Does that compile for you? Which version of GCC do we end up using on >> Windows? >> >> The reported symbol (___sync_fetch_and_add_1) has three leading >> underscores, that looks weird. Can you compile just >> libraries/ghc-prim/cbits/atomic.c and see if it's indeed GCC that generates >> a reference to that symbol? >> >> 1. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html >> >> >> On Wed, Jul 16, 2014 at 12:29 AM, Simon Peyton Jones < >> simonpj(a)microsoft.com> wrote: >> >>> Aargh! The Windows build has broken – again. I can’t build GHC on >>> my laptop any more. >>> >>> A clean ‘sh validate’ finishes as below. What on earth is >>> `___sync_fetch_and_add_1'? >>> >>> Can anyone help? Thanks! >>> >>> Simon >>> >>> "inplace/bin/ghc-stage2.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m >>> -O -Werror -Wall -H64m -O0 -package-name vector-0.10.9.1 >>> -hide-all-packages -i -ilibraries/vector/. >>> -ilibraries/vector/dist-install/build >>> -ilibraries/vector/dist-install/build/autogen >>> -Ilibraries/vector/dist-install/build >>> -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include >>> -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include >>> -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package >>> base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package >>> primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O >>> -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts >>> -Wwarn -odir libraries/vector/dist-install/build -hidir >>> libraries/vector/dist-install/build -stubdir >>> libraries/vector/dist-install/build -c >>> libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o >>> libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o >>> >>> Loading package ghc-prim ... linking ... ghc-stage2.exe: unable to load >>> package `ghc-prim' >>> >>> ghc-stage2.exe: >>> C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.3.1.0.o: >>> unknown symbol `___sync_fetch_and_add_1' >>> >>> libraries/vector/ghc.mk:5: recipe for target >>> 'libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o' >>> failed >>> >>> make[1]: *** >>> [libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o] >>> Error 1 >>> >>> >>> >>> I >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> >> >

7 21

The build is broken? (Haddock parse error)
by Páli Gábor János 17 Jul '14

17 Jul '14

Hello there, I have just found the builds are failing due to this (see [1] for the full log): "/usr/home/ghc-builder/work/builder/tempbuild/build/inplace/bin/haddock" --odir="compiler/stage2/doc/html/ghc" --no-tmp-comp-dir --dump-interface=compiler/stage2/doc/html/ghc/ghc.haddock --html --hoogle --title="ghc-7.9.20140717: The GHC API" --prologue="compiler/stage2/haddock-prologue.txt" --read-interface=../Cabal-1.20.0.1,../Cabal-1.20.0.1/src/%{MODULE/./-}.html\#%{NAME},libraries/Cabal/Cabal/dist-install/doc/html/Cabal/Cabal.haddock --read-interface=../array-0.5.0.0,../array-0.5.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/array/dist-install/doc/html/array/array.haddock --read-interface=../base-4.7.1.0,../base-4.7.1.0/src/%{MODULE/./-}.html\#%{NAME},libraries/base/dist-install/doc/html/base/base.haddock --read-interface=../bin-package-db-0.0.0.0,../bin-package-db-0.0.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/bin-package-db/dist-install/doc/html/bin-package-db/bin-package-db.haddock --read-interface=../bytestring-0.10.4.0,../bytestring-0.10.4.0/src/%{MODULE/./-}.html\#%{NAME},libraries/bytestring/dist-install/doc/html/bytestring/bytestring.haddock --read-interface=../containers-0.5.5.1,../containers-0.5.5.1/src/%{MODULE/./-}.html\#%{NAME},libraries/containers/dist-install/doc/html/containers/containers.haddock --read-interface=../directory-1.2.1.0,../directory-1.2.1.0/src/%{MODULE/./-}.html\#%{NAME},libraries/directory/dist-install/doc/html/directory/directory.haddock --read-interface=../filepath-1.3.0.2,../filepath-1.3.0.2/src/%{MODULE/./-}.html\#%{NAME},libraries/filepath/dist-install/doc/html/filepath/filepath.haddock --read-interface=../hoopl-3.10.0.1,../hoopl-3.10.0.1/src/%{MODULE/./-}.html\#%{NAME},libraries/hoopl/dist-install/doc/html/hoopl/hoopl.haddock --read-interface=../hpc-0.6.0.1,../hpc-0.6.0.1/src/%{MODULE/./-}.html\#%{NAME},libraries/hpc/dist-install/doc/html/hpc/hpc.haddock --read-interface=../process-1.2.0.0,../process-1.2.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/process/dist-install/doc/html/process/process.haddock --read-interface=../template-haskell-2.10.0.0,../template-haskell-2.10.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/template-haskell/dist-install/doc/html/template-haskell/template-haskell.haddock --read-interface=../time-1.4.2,../time-1.4.2/src/%{MODULE/./-}.html\#%{NAME},libraries/time/dist-install/doc/html/time/time.haddock --read-interface=../transformers-0.4.1.0,../transformers-0.4.1.0/src/%{MODULE/./-}.html\#%{NAME},libraries/transformers/dist-install/doc/html/transformers/transformers.haddock --read-interface=../unix-2.7.0.2,../unix-2.7.0.2/src/%{MODULE/./-}.html\#%{NAME},libraries/unix/dist-install/doc/html/unix/unix.haddock --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-H32m --optghc=-O --optghc=-package-name --optghc=ghc-7.9.20140717 --optghc=-hide-all-packages --optghc=-i --optghc=-icompiler/basicTypes --optghc=-icompiler/cmm --optghc=-icompiler/codeGen --optghc=-icompiler/coreSyn --optghc=-icompiler/deSugar --optghc=-icompiler/ghci --optghc=-icompiler/hsSyn --optghc=-icompiler/iface --optghc=-icompiler/llvmGen --optghc=-icompiler/main --optghc=-icompiler/nativeGen --optghc=-icompiler/parser --optghc=-icompiler/prelude --optghc=-icompiler/profiling --optghc=-icompiler/rename --optghc=-icompiler/simplCore --optghc=-icompiler/simplStg --optghc=-icompiler/specialise --optghc=-icompiler/stgSyn --optghc=-icompiler/stranal --optghc=-icompiler/typecheck --optghc=-icompiler/types --optghc=-icompiler/utils --optghc=-icompiler/vectorise --optghc=-icompiler/stage2/build --optghc=-icompiler/stage2/build/autogen --optghc=-Icompiler/stage2/build --optghc=-Icompiler/stage2/build/autogen --optghc=-Icompiler/. --optghc=-Icompiler/parser --optghc=-Icompiler/utils --optghc=-Icompiler/../rts/dist/build --optghc=-Icompiler/stage2 --optghc=-optP-DGHCI --optghc=-optP-include --optghc=-optPcompiler/stage2/build/autogen/cabal_macros.h --optghc=-package --optghc=Cabal-1.20.0.1 --optghc=-package --optghc=array-0.5.0.0 --optghc=-package --optghc=base-4.7.1.0 --optghc=-package --optghc=bin-package-db-0.0.0.0 --optghc=-package --optghc=bytestring-0.10.4.0 --optghc=-package --optghc=containers-0.5.5.1 --optghc=-package --optghc=directory-1.2.1.0 --optghc=-package --optghc=filepath-1.3.0.2 --optghc=-package --optghc=hoopl-3.10.0.1 --optghc=-package --optghc=hpc-0.6.0.1 --optghc=-package --optghc=process-1.2.0.0 --optghc=-package --optghc=template-haskell-2.10.0.0 --optghc=-package --optghc=time-1.4.2 --optghc=-package --optghc=transformers-0.4.1.0 --optghc=-package --optghc=unix-2.7.0.2 --optghc=-Wall --optghc=-fno-warn-name-shadowing --optghc=-XHaskell2010 --optghc=-optc-DTHREADED_RTS --optghc=-DGHCI_TABLES_NEXT_TO_CODE --optghc=-DSTAGE=2 --optghc=-Rghc-timing --optghc=-O2 --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir --optghc=compiler/stage2/build --optghc=-hidir --optghc=compiler/stage2/build --optghc=-stubdir --optghc=compiler/stage2/build --source-module=src/%{MODULE/./-}.html --source-entity=src/%{MODULE/./-}.html#%{NAME} --optghc=-DSTAGE=2 compiler/basicTypes/Avail.hs compiler/basicTypes/BasicTypes.lhs compiler/basicTypes/ConLike.lhs compiler/basicTypes/DataCon.lhs compiler/basicTypes/PatSyn.lhs compiler/basicTypes/Demand.lhs compiler/utils/Exception.hs compiler/main/GhcMonad.hs compiler/main/Hooks.lhs compiler/basicTypes/Id.lhs compiler/basicTypes/IdInfo.lhs compiler/basicTypes/Literal.lhs compiler/llvmGen/Llvm.hs compiler/llvmGen/Llvm/AbsSyn.hs compiler/llvmGen/Llvm/MetaData.hs compiler/llvmGen/Llvm/PpLlvm.hs compiler/llvmGen/Llvm/Types.hs compiler/llvmGen/LlvmCodeGen.hs compiler/llvmGen/LlvmCodeGen/Base.hs compiler/llvmGen/LlvmCodeGen/CodeGen.hs compiler/llvmGen/LlvmCodeGen/Data.hs compiler/llvmGen/LlvmCodeGen/Ppr.hs compiler/llvmGen/LlvmCodeGen/Regs.hs compiler/llvmGen/LlvmMangler.hs compiler/basicTypes/MkId.lhs compiler/basicTypes/Module.lhs compiler/basicTypes/Name.lhs compiler/basicTypes/NameEnv.lhs compiler/basicTypes/NameSet.lhs compiler/basicTypes/OccName.lhs compiler/basicTypes/RdrName.lhs compiler/basicTypes/SrcLoc.lhs compiler/basicTypes/UniqSupply.lhs compiler/basicTypes/Unique.lhs compiler/basicTypes/Var.lhs compiler/basicTypes/VarEnv.lhs compiler/basicTypes/VarSet.lhs compiler/utils/UnVarGraph.hs compiler/cmm/BlockId.hs compiler/cmm/CLabel.hs compiler/cmm/Cmm.hs compiler/cmm/CmmBuildInfoTables.hs compiler/cmm/CmmPipeline.hs compiler/cmm/CmmCallConv.hs compiler/cmm/CmmCommonBlockElim.hs compiler/cmm/CmmContFlowOpt.hs compiler/cmm/CmmExpr.hs compiler/cmm/CmmInfo.hs compiler/stage2/build/CmmLex.hs compiler/cmm/CmmLint.hs compiler/cmm/CmmLive.hs compiler/cmm/CmmMachOp.hs compiler/cmm/CmmNode.hs compiler/cmm/CmmOpt.hs compiler/stage2/build/CmmParse.hs compiler/cmm/CmmProcPoint.hs compiler/cmm/CmmSink.hs compiler/cmm/CmmType.hs compiler/cmm/CmmUtils.hs compiler/cmm/CmmLayoutStack.hs compiler/cmm/MkGraph.hs compiler/nativeGen/PprBase.hs compiler/cmm/PprC.hs compiler/cmm/PprCmm.hs compiler/cmm/PprCmmDecl.hs compiler/cmm/PprCmmExpr.hs compiler/cmm/Bitmap.hs compiler/codeGen/CodeGen/Platform.hs compiler/codeGen/CodeGen/Platform/ARM.hs compiler/codeGen/CodeGen/Platform/NoRegs.hs compiler/codeGen/CodeGen/Platform/PPC.hs compiler/codeGen/CodeGen/Platform/PPC_Darwin.hs compiler/codeGen/CodeGen/Platform/SPARC.hs compiler/codeGen/CodeGen/Platform/X86.hs compiler/codeGen/CodeGen/Platform/X86_64.hs compiler/codeGen/CgUtils.hs compiler/codeGen/StgCmm.hs compiler/codeGen/StgCmmBind.hs compiler/codeGen/StgCmmClosure.hs compiler/codeGen/StgCmmCon.hs compiler/codeGen/StgCmmEnv.hs compiler/codeGen/StgCmmExpr.hs compiler/codeGen/StgCmmForeign.hs compiler/codeGen/StgCmmHeap.hs compiler/codeGen/StgCmmHpc.hs compiler/codeGen/StgCmmArgRep.hs compiler/codeGen/StgCmmLayout.hs compiler/codeGen/StgCmmMonad.hs compiler/codeGen/StgCmmPrim.hs compiler/codeGen/StgCmmProf.hs compiler/codeGen/StgCmmTicky.hs compiler/codeGen/StgCmmUtils.hs compiler/codeGen/StgCmmExtCode.hs compiler/cmm/SMRep.lhs compiler/coreSyn/CoreArity.lhs compiler/coreSyn/CoreFVs.lhs compiler/coreSyn/CoreLint.lhs compiler/coreSyn/CorePrep.lhs compiler/coreSyn/CoreSubst.lhs compiler/coreSyn/CoreSyn.lhs compiler/coreSyn/TrieMap.lhs compiler/coreSyn/CoreTidy.lhs compiler/coreSyn/CoreUnfold.lhs compiler/coreSyn/CoreUtils.lhs compiler/coreSyn/MkCore.lhs compiler/coreSyn/PprCore.lhs compiler/deSugar/Check.lhs compiler/deSugar/Coverage.lhs compiler/deSugar/Desugar.lhs compiler/deSugar/DsArrows.lhs compiler/deSugar/DsBinds.lhs compiler/deSugar/DsCCall.lhs compiler/deSugar/DsExpr.lhs compiler/deSugar/DsForeign.lhs compiler/deSugar/DsGRHSs.lhs compiler/deSugar/DsListComp.lhs compiler/deSugar/DsMonad.lhs compiler/deSugar/DsUtils.lhs compiler/deSugar/Match.lhs compiler/deSugar/MatchCon.lhs compiler/deSugar/MatchLit.lhs compiler/hsSyn/HsBinds.lhs compiler/hsSyn/HsDecls.lhs compiler/hsSyn/HsDoc.hs compiler/hsSyn/HsExpr.lhs compiler/hsSyn/HsImpExp.lhs compiler/hsSyn/HsLit.lhs compiler/hsSyn/HsPat.lhs compiler/hsSyn/HsSyn.lhs compiler/hsSyn/HsTypes.lhs compiler/hsSyn/HsUtils.lhs compiler/iface/BinIface.hs compiler/iface/BuildTyCl.lhs compiler/iface/IfaceEnv.lhs compiler/iface/IfaceSyn.lhs compiler/iface/IfaceType.lhs compiler/iface/LoadIface.lhs compiler/iface/MkIface.lhs compiler/iface/TcIface.lhs compiler/iface/FlagChecker.hs compiler/main/Annotations.hs compiler/main/BreakArray.hs compiler/main/CmdLineParser.hs compiler/main/CodeOutput.lhs compiler/stage2/build/Config.hs compiler/main/Constants.lhs compiler/main/DriverMkDepend.hs compiler/main/DriverPhases.hs compiler/main/PipelineMonad.hs compiler/main/DriverPipeline.hs compiler/main/DynFlags.hs compiler/main/ErrUtils.lhs compiler/main/Finder.lhs compiler/main/GHC.hs compiler/main/GhcMake.hs compiler/main/GhcPlugins.hs compiler/main/DynamicLoading.hs compiler/main/HeaderInfo.hs compiler/main/HscMain.hs compiler/main/HscStats.hs compiler/main/HscTypes.lhs compiler/main/InteractiveEval.hs compiler/main/InteractiveEvalTypes.hs compiler/main/PackageConfig.hs compiler/main/Packages.lhs compiler/main/PlatformConstants.hs compiler/main/PprTyThing.hs compiler/main/StaticFlags.hs compiler/main/SysTools.lhs compiler/main/TidyPgm.lhs compiler/parser/Ctype.lhs compiler/parser/HaddockUtils.hs compiler/stage2/build/Lexer.hs compiler/types/OptCoercion.lhs compiler/stage2/build/Parser.hs compiler/parser/RdrHsSyn.lhs compiler/prelude/ForeignCall.lhs compiler/prelude/PrelInfo.lhs compiler/prelude/PrelNames.lhs compiler/prelude/PrelRules.lhs compiler/prelude/PrimOp.lhs compiler/prelude/TysPrim.lhs compiler/prelude/TysWiredIn.lhs compiler/profiling/CostCentre.lhs compiler/profiling/ProfInit.hs compiler/profiling/SCCfinal.lhs compiler/rename/RnBinds.lhs compiler/rename/RnEnv.lhs compiler/rename/RnExpr.lhs compiler/rename/RnHsDoc.hs compiler/rename/RnNames.lhs compiler/rename/RnPat.lhs compiler/rename/RnSource.lhs compiler/rename/RnSplice.lhs compiler/rename/RnTypes.lhs compiler/simplCore/CoreMonad.lhs compiler/simplCore/CSE.lhs compiler/simplCore/FloatIn.lhs compiler/simplCore/FloatOut.lhs compiler/simplCore/LiberateCase.lhs compiler/simplCore/OccurAnal.lhs compiler/simplCore/SAT.lhs compiler/simplCore/SetLevels.lhs compiler/simplCore/SimplCore.lhs compiler/simplCore/SimplEnv.lhs compiler/simplCore/SimplMonad.lhs compiler/simplCore/SimplUtils.lhs compiler/simplCore/Simplify.lhs compiler/simplStg/SimplStg.lhs compiler/simplStg/StgStats.lhs compiler/simplStg/UnariseStg.lhs compiler/specialise/Rules.lhs compiler/specialise/SpecConstr.lhs compiler/specialise/Specialise.lhs compiler/stgSyn/CoreToStg.lhs compiler/stgSyn/StgLint.lhs compiler/stgSyn/StgSyn.lhs compiler/simplCore/CallArity.hs compiler/stranal/DmdAnal.lhs compiler/stranal/WorkWrap.lhs compiler/stranal/WwLib.lhs compiler/typecheck/FamInst.lhs compiler/typecheck/Inst.lhs compiler/typecheck/TcAnnotations.lhs compiler/typecheck/TcArrows.lhs compiler/typecheck/TcBinds.lhs compiler/typecheck/TcClassDcl.lhs compiler/typecheck/TcDefaults.lhs compiler/typecheck/TcDeriv.lhs compiler/typecheck/TcEnv.lhs compiler/typecheck/TcExpr.lhs compiler/typecheck/TcForeign.lhs compiler/typecheck/TcGenDeriv.lhs compiler/typecheck/TcGenGenerics.lhs compiler/typecheck/TcHsSyn.lhs compiler/typecheck/TcHsType.lhs compiler/typecheck/TcInstDcls.lhs compiler/typecheck/TcMType.lhs compiler/typecheck/TcValidity.lhs compiler/typecheck/TcMatches.lhs compiler/typecheck/TcPat.lhs compiler/typecheck/TcPatSyn.lhs compiler/typecheck/TcRnDriver.lhs compiler/typecheck/TcRnMonad.lhs compiler/typecheck/TcRnTypes.lhs compiler/typecheck/TcRules.lhs compiler/typecheck/TcSimplify.lhs compiler/typecheck/TcErrors.lhs compiler/typecheck/TcTyClsDecls.lhs compiler/typecheck/TcTyDecls.lhs compiler/typecheck/TcType.lhs compiler/typecheck/TcEvidence.lhs compiler/typecheck/TcUnify.lhs compiler/typecheck/TcInteract.lhs compiler/typecheck/TcCanonical.lhs compiler/typecheck/TcSMonad.lhs compiler/typecheck/TcTypeNats.hs compiler/typecheck/TcSplice.lhs compiler/types/Class.lhs compiler/types/Coercion.lhs compiler/types/FamInstEnv.lhs compiler/typecheck/FunDeps.lhs compiler/types/InstEnv.lhs compiler/types/TyCon.lhs compiler/types/CoAxiom.lhs compiler/types/Kind.lhs compiler/types/Type.lhs compiler/types/TypeRep.lhs compiler/types/Unify.lhs compiler/utils/Bag.lhs compiler/utils/Binary.hs compiler/utils/BooleanFormula.hs compiler/utils/BufWrite.hs compiler/utils/Digraph.lhs compiler/utils/Encoding.hs compiler/utils/FastBool.lhs compiler/utils/FastFunctions.lhs compiler/utils/FastMutInt.lhs compiler/utils/FastString.lhs compiler/utils/FastTypes.lhs compiler/stage2/build/Fingerprint.hs compiler/utils/FiniteMap.lhs compiler/utils/GraphBase.hs compiler/utils/GraphColor.hs compiler/utils/GraphOps.hs compiler/utils/GraphPpr.hs compiler/utils/IOEnv.hs compiler/utils/ListSetOps.lhs compiler/utils/Maybes.lhs compiler/utils/MonadUtils.hs compiler/utils/OrdList.lhs compiler/utils/Outputable.lhs compiler/utils/Pair.lhs compiler/utils/Panic.lhs compiler/utils/Pretty.lhs compiler/utils/Serialized.hs compiler/utils/State.hs compiler/utils/Stream.hs compiler/utils/StringBuffer.lhs compiler/utils/UniqFM.lhs compiler/utils/UniqSet.lhs compiler/utils/Util.lhs compiler/utils/ExtsCompat46.hs compiler/vectorise/Vectorise/Builtins/Base.hs compiler/vectorise/Vectorise/Builtins/Initialise.hs compiler/vectorise/Vectorise/Builtins.hs compiler/vectorise/Vectorise/Monad/Base.hs compiler/vectorise/Vectorise/Monad/Naming.hs compiler/vectorise/Vectorise/Monad/Local.hs compiler/vectorise/Vectorise/Monad/Global.hs compiler/vectorise/Vectorise/Monad/InstEnv.hs compiler/vectorise/Vectorise/Monad.hs compiler/vectorise/Vectorise/Utils/Base.hs compiler/vectorise/Vectorise/Utils/Closure.hs compiler/vectorise/Vectorise/Utils/Hoisting.hs compiler/vectorise/Vectorise/Utils/PADict.hs compiler/vectorise/Vectorise/Utils/Poly.hs compiler/vectorise/Vectorise/Utils.hs compiler/vectorise/Vectorise/Generic/Description.hs compiler/vectorise/Vectorise/Generic/PAMethods.hs compiler/vectorise/Vectorise/Generic/PADict.hs compiler/vectorise/Vectorise/Generic/PData.hs compiler/vectorise/Vectorise/Type/Env.hs compiler/vectorise/Vectorise/Type/Type.hs compiler/vectorise/Vectorise/Type/TyConDecl.hs compiler/vectorise/Vectorise/Type/Classify.hs compiler/vectorise/Vectorise/Convert.hs compiler/vectorise/Vectorise/Vect.hs compiler/vectorise/Vectorise/Var.hs compiler/vectorise/Vectorise/Env.hs compiler/vectorise/Vectorise/Exp.hs compiler/vectorise/Vectorise.hs compiler/cmm/Hoopl/Dataflow.hs compiler/cmm/Hoopl.hs compiler/nativeGen/AsmCodeGen.lhs compiler/nativeGen/TargetReg.hs compiler/nativeGen/NCGMonad.hs compiler/nativeGen/Instruction.hs compiler/nativeGen/Size.hs compiler/nativeGen/Reg.hs compiler/nativeGen/RegClass.hs compiler/nativeGen/PIC.hs compiler/utils/Platform.hs compiler/nativeGen/CPrim.hs compiler/nativeGen/X86/Regs.hs compiler/nativeGen/X86/RegInfo.hs compiler/nativeGen/X86/Instr.hs compiler/nativeGen/X86/Cond.hs compiler/nativeGen/X86/Ppr.hs compiler/nativeGen/X86/CodeGen.hs compiler/nativeGen/PPC/Regs.hs compiler/nativeGen/PPC/RegInfo.hs compiler/nativeGen/PPC/Instr.hs compiler/nativeGen/PPC/Cond.hs compiler/nativeGen/PPC/Ppr.hs compiler/nativeGen/PPC/CodeGen.hs compiler/nativeGen/SPARC/Base.hs compiler/nativeGen/SPARC/Regs.hs compiler/nativeGen/SPARC/Imm.hs compiler/nativeGen/SPARC/AddrMode.hs compiler/nativeGen/SPARC/Cond.hs compiler/nativeGen/SPARC/Instr.hs compiler/nativeGen/SPARC/Stack.hs compiler/nativeGen/SPARC/ShortcutJump.hs compiler/nativeGen/SPARC/Ppr.hs compiler/nativeGen/SPARC/CodeGen.hs compiler/nativeGen/SPARC/CodeGen/Amode.hs compiler/nativeGen/SPARC/CodeGen/Base.hs compiler/nativeGen/SPARC/CodeGen/CondCode.hs compiler/nativeGen/SPARC/CodeGen/Gen32.hs compiler/nativeGen/SPARC/CodeGen/Gen64.hs compiler/nativeGen/SPARC/CodeGen/Sanity.hs compiler/nativeGen/SPARC/CodeGen/Expand.hs compiler/nativeGen/RegAlloc/Liveness.hs compiler/nativeGen/RegAlloc/Graph/Main.hs compiler/nativeGen/RegAlloc/Graph/Stats.hs compiler/nativeGen/RegAlloc/Graph/ArchBase.hs compiler/nativeGen/RegAlloc/Graph/ArchX86.hs compiler/nativeGen/RegAlloc/Graph/Coalesce.hs compiler/nativeGen/RegAlloc/Graph/Spill.hs compiler/nativeGen/RegAlloc/Graph/SpillClean.hs compiler/nativeGen/RegAlloc/Graph/SpillCost.hs compiler/nativeGen/RegAlloc/Graph/TrivColorable.hs compiler/nativeGen/RegAlloc/Linear/Main.hs compiler/nativeGen/RegAlloc/Linear/JoinToTargets.hs compiler/nativeGen/RegAlloc/Linear/State.hs compiler/nativeGen/RegAlloc/Linear/Stats.hs compiler/nativeGen/RegAlloc/Linear/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/StackMap.hs compiler/nativeGen/RegAlloc/Linear/Base.hs compiler/nativeGen/RegAlloc/Linear/X86/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/X86_64/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/PPC/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/SPARC/FreeRegs.hs compiler/deSugar/DsMeta.hs compiler/hsSyn/Convert.lhs compiler/ghci/ByteCodeAsm.lhs compiler/ghci/ByteCodeGen.lhs compiler/ghci/ByteCodeInstr.lhs compiler/ghci/ByteCodeItbls.lhs compiler/ghci/ByteCodeLink.lhs compiler/ghci/Debugger.hs compiler/stage2/build/LibFFI.hs compiler/ghci/Linker.lhs compiler/ghci/ObjLink.lhs compiler/ghci/RtClosureInspect.hs compiler/ghci/DebuggerUtils.hs +RTS -tcompiler/stage2/doc/html/ghc/ghc.haddock.t --machine-readable compiler/types/Coercion.lhs:1892:3: parse error on input ‘-- *kind* and role of its argument. Luckily, laziness should’ [1] http://haskell.inf.elte.hu/builders/freebsd-amd64-head/322/10.html

5 4

RFC: style cleanup & guidelines for GHC, and related bikeshedding
by Austin Seipp 17 Jul '14

17 Jul '14

Hi *, First off, WARNING: BIKESHEDDING AHEAD. With that out of the way - today on IRC, there was some discussion about some stylistic/consistency issues in GHC, and being spurred by Johans recent proposal for top-level documentation, I figured perhaps we should beat the drum on this issue as well. The TL;DR is that GHC has a lot of inconsistent style issues, including things like: - Mixing literate haskell with non-literate haskell files - Legacy code with tabs and spaces intermixed - Related to the last one, trailing whitespace - Mixing styles of do notation in different parts of the compiler (braces vs no braces) - Probably things like indentation mismatches even in the same code - Probably many other things I've missed, obvious or not. These issues by themselves aren't too bad, but together they make the coding style for GHC very inconsistent, and this hurts maintainability a bit I feel. Furthermore, some of these issues block related improvements - for example, https://ghc.haskell.org/trac/ghc/ticket/9230 which is probably quite reasonable will likely be a bit annoying to implement until GHC itself is de-tabbed - we use -Werror during ./validate. This particular issue is what started the discussion. Also, with developers now using arcanist and phabricator, they have linting enabled for new patches, but they will often warn about surrounding issues, mostly tabs and trailing spaces. This is a bit annoying for submitters, and would be fixed by enforcing it. First attack plan ~~~~~~~~~~~~~~~ So, to start, I'd like to propose that we make some guidelines for these kinds of things, and also a plan to fix some of them. To start: #1) We should really consider going ahead and detabbing the remaining files that have them. We already enforce this on new commits with git hooks, but by doing this, we can make -fwarn-tabs a default flag and then validate with -Werror in the development process. #2) Similarly, we should kill all the trailing whitespace. (I think this is less controversial than #1) #3) We should most certainly move the remaining files from literate haskell to non-literate haskell. Most of the files in the compiler are already in this form, and the literate haskell documentation can't be used to generate PDFs or anything similar. I suggest we get rid of it. More Haskell users use non-literate files anyway. This is probably the least controversial. Merge issues ~~~~~~~~~~~~~~~~~ The reason we haven't done the above three things historically is that it makes merge conflicts nastier. A useful approximation suggested on IRC might be to detab and remove whitespace for files older than a certain date (say, 6 months). However, in general I'm thinking perhaps it's best to go ahead and bite the bullet. maybe. I'd like to know what other people think! If we have a vote and most people are in favor of doing this, maybe we should really do it. I'd especially like to hear about this if you have an outstanding branch. Some numbers on these issues ~~~~~~~~~~~~~~~~~~~~~~~~ Here are some quick numbers on where most of the tabs reside, as well as the breakdown of literate files vs non-literate files. NOTE: these tests occurred in the 'compiler' subdirectory of the GHC repository, which is where most of the relevant code is. LITERATE vs NON-LITERATE: $ find . -type f -iname '*.hs' | wc -l 206 $ find . -type f -iname '*.lhs' | wc -l 194 Non-literate wins by a slim margin! But having the compiler divided in half is really not a good thing IMO... NUMBER OF TABS PER SUBDIRECTORY: NOTE: this counts the number of lines which have tabs in them. It does not count the total number of tab occurrences. $ for x in `echo */`; do echo -n "$x:\t\t"; find $x -type f -regex '.*\.$lhs\|hs$' | xargs grep -P '\t' | wc -l; done basicTypes/: 919 cbits/: 0 cmm/: 38 codeGen/: 0 coreSyn/: 843 deSugar/: 545 ghci/: 90 hsSyn/: 120 iface/: 213 llvmGen/: 0 main/: 8 nativeGen/: 1213 parser/: 19 prelude/: 182 profiling/: 39 rename/: 188 simplCore/: 754 simplStg/: 0 specialise/: 0 stgSyn/: 0 stranal/: 336 typecheck/: 1171 types/: 301 utils/: 220 vectorise/: 0 >From these numbers, we can see a few useful things at least, primarily that there are definitely some places where removing tabs should be easy. For example, parser/, profiling/, main/, and cmm/ can all be de-tabbed without much of a problem, I think. nativeGen is very often not touched, so even though it has a *huge* amount of tabs, it can likely be de-tabbed as well with minimal impact. Other style issues ~~~~~~~~~~~~~~~~~ We should also discuss some related issues, like what general block-width to use for indentations, naming conventions, and other stuff. However, I leave this all to you, and perhaps it is best we split that part off into a separate thread. Some things I'd like you all to consider: - Block width for indentation - Naming conventions (we use camelCase and_underscores_sometimes which isReally_confusing) - Import/export styles (I think we have some sloppiness here too) - Other things worth arguing forever about. Thoughts on the above issues? -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

12 19