- ghc-devs - Haskell.org

GHC Weekly News - 2014/12/08
by Austin Seipp 08 Dec '14

08 Dec '14

Hi *, Once more, it's time for some news about GHC! This week's regularly scheduled programming (get it?) has brought you... - As of last week, GHC officially has no more `.lhs` files in its source repository; instead, they've all been converted to `.hs` and are now much more consistent with each other: https://www.haskell.org/pipermail/ghc-devs/2014-December/007552.html - Joachim Breitner has reported that the `linker_unload` test in GHC has been failing, but it's been surprisingly hard to reproduce reliably on our build machines! https://www.haskell.org/pipermail/ghc-devs/2014-December/007528.html - Moritz Angermann posted a proposal about the "Out of Process Template Haskell" project, started by the GHCJS developers. In short, they want to work out how to get Template Haskell working in a stage2 GHC for things like iOS or Browser devices: https://www.haskell.org/pipermail/ghc-devs/2014-December/007555.html - Lennart Augustsson has an inquiry about his program: why is it running out of memory? But the stranger thing: why does it only run out if heap profiling ''is not enabled''? Nobody has quite figured out, but if you're a guru, it may be a good chance to help out: https://www.haskell.org/pipermail/ghc-devs/2014-December/007582.html - Yuras Shumovich tracked down some nasty bugs in the typechecker's linter, causing several programs to fail to work when compiled by GHC. A quick diagnosis, but no fix has been merged quite yet: https://www.haskell.org/pipermail/ghc-devs/2014-December/007580.html - Richard Eisenberg wants feedback on a what he thinks is a design wart in the use of `-XStandaloneDeriving`, and he's not only proposed a solution, but wants to know what people think; typechecking fans are surely puzzling away already: https://www.haskell.org/pipermail/ghc-devs/2014-December/007589.html - David Spies has run into an interesting situation: why does -O make his program **slower** instead of faster? Well, nobody has quite figured out why yet, but it's an interesting question - maybe on a lazy monday developer can help figure out: https://www.haskell.org/pipermail/ghc-devs/2014-December/thread.html - Richard E. has another thread on the list, this time about development work flows: what do we do about painful merges? https://www.haskell.org/pipermail/ghc-devs/2014-December/007586.html Closed tickets this week include: #9850, #9005, #9828, #9833, #9582, #8935, #9186, #9480, #9497, #7908, #4347, #3977, #3859, #3844, #3814, #3771, #3739, #2182, #9812, #4921, #7947, #9240, #5401, #3625, #3517, #9444, #9142, #3447, #8894, #3065, #3191, #2697, #2836, #5443, #7736, #2489, #2456, #2204, #9777, #9859, #9869, #9808 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

inferred contexts from `deriving`
by Richard Eisenberg 08 Dec '14

08 Dec '14

Hi devs, I've just hit on (what I view to be) a design wart in what is allowed in an instance context inferred through the use of non-standalone `deriving`. I've posed a problem and potential solution in #8984 (https://ghc.haskell.org/trac/ghc/ticket/8984#comment:6) See Note [Exotic derived instance contexts] (https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcDeriv.hs#L1915) for some background info. I would love input on this issue, as it all boils down to a simple design choice. The implementation is dead easy no matter what. Please post any further comments to the ticket, but I wanted to bleat here because it seems easy to ignore emails from #8984, whose title is about tweaking an error message. Thanks, Richard

1 0

painful merges
by Richard Eisenberg 07 Dec '14

07 Dec '14

Hi devs, There are various times when we want to make some change to a large number of lines/files, but the change is very very boring. Two somewhat recent cases that come to mind are de-tabbing and the .lhs -> .hs conversion. These sorts of changes cause painful merges for anyone who is working on a branch. However, this pain is mitigated substantially if two properties hold: 1) The commit does *nothing* interesting. 2) The branch-writer knows about the commit in question. If these two properties hold, then the branch-writer can merge with the commit previous to the painful one, resolve all conflicts, and then merge the painful commit. During the painful merge, the branch-writer can be blissfully carefree about understanding the code -- after all, the painful merge is uninteresting and mechanical. Then, the branch-writer can continuing merging more commits, paying closer attention. In most cases, it should be easy for us to maintain property (1) going forward. Property (2) is harder, so I propose the following: ** All commits expected to be painful to merge, but are otherwise uninteresting, include "[painful merge]" in the commit message. ** This seems to be a really easy workflow to implement, and it would make, for example, the long, drawn-out debate over detabbing perhaps easier to resolve. Bikeshedding over the keyword [painful merge] welcome, along with more constructive comments. Is anyone aware of this convention implemented in other projects? Thanks, Richard

1 0

testsuite no longer parellel?
by Richard Eisenberg 07 Dec '14

07 Dec '14

Hi devs, Previously, I've had much success with the THREADS environment variable for getting the testsuite to run multiple tests in parallel. This no longer seems to be working on my Macs. Is this an expected change? Is there something I can do to fix this locally? It takes a long time to run tests one at a time! Thanks! Richard

1 0

ghc.haskell.org
by Simon Peyton Jones 05 Dec '14

05 Dec '14

Is it just me, or is ghc.haskell.org very slow at serving up Trac pages today?

1 0

API Annotations for pragmas
by Alan & Kim Zimmerman 05 Dec '14

05 Dec '14

It seems that pragma definitions in source are not only case insensitive, but can accept UK or US spelling variants. I am going to need to capture SourceText values in the tokens, and bring them through into the AST. Alan

2 2

Out Of Process Template Haskell
by Moritz Angermann 04 Dec '14

04 Dec '14

Hi, as you may or may not know, template haskell is not available to cross compilers. And therefore cross compiler are devoid of an important feature of haskell. We are currently building ghc cross compiler as stage1 compiler with a foreign target. This means that we use a stage0 compiler (the one that is used to build ghc), to build the ghc that will run on the host and produce binaries for the target (e.g. running on x86_64, building for arm). Template Haskell and GHCi are enabled only in stage2. To build a stage2 compiler we use the stage1 compiler. Hence the stage2 compiler runs on the target of the stage1 compiler. A motivating example could be ghc running on an Intel based Mac OS X targeting iOS (ARM). A *theoretical* stage2 compiler could have GHCi and Template Haskell, but would run on the iOS Device, which is neat but probably not a practical solution. Hence a compiler running on a more powerful host, producing executables for a foreign target can be a very good solution when the host is much more powerful. (Ref. [1]). In [2] we can read the following: > Stage 1 does not support interactive execution (GHCi) and Template Haskell. The reason > being that when running byte code we must dynamically link the packages, and only in > stage 2 and later can we guarantee that the packages we dynamically link are compatible > with those that GHC was built against (because they are the very same packages). One of the prominent cross compilers is ghcjs, which admittedly is build a little different than the above cross compiler would be. ghcjs shares the same template haskell issue though. ghcjs--to my knowledge--followed a few different routes to solve this. And finally came up with the *out-of-process-template-haskell* solution. The Out Of Process Template Haskell approach works by having a *runner* on the target that waits for the compiler to send the template haskell splices, and compiles those splices on the target, whilte querying the *master* ghc for potential lookups during the splice compilation. The result is then shipped back to the host to integrate into the produced binary for the target. Hence allowing the more powerful host to do the bulk of the compilation and using the *runner* as a *slave compiler* on the target. .-- host -. .- target -. | | -- ( encounters splice and sends it to runner ) ---> | | | | | | | ghc | .<---- ( compiles and queries ghc for lookups ) ----. | runner | | master | '----------- ( responds to to queries ) ----------->' | slave | | | | | | | <- ( receives the compiled splice from the runner ) - | | '---------' '----------' Fig. 1: ghc - th runner communication. I have implemented the *out-of-process-template-haskell* approach with the help from luite for ghc as a plugin for stage2 *non*-cross compiler[3] using dynamic libraries and a tcp transport by adapting the code from ghcjs to run on the host. Obviously for a regular stage2 ghc, which has GHCi and Template Haskell, this doesn't really buy anyone anything yet. Also a plugin is impossible to load into a stage1 compiler yet, as the plugin code is wrapped in #ifdef GHCI sections. SIDENOTE: To allow the out-of-process-template-haskell, the plugin api had to be adapted minimally to allow plugins to install hooks. Patches for 7.8[4] and 7.10[5] are readily available. Clearly the *out-of-process-template-haskell* could be integrated into the ghc tree by hard wiring it in, where the plugin did the wiring ad-hoc previous. This would imply that ghc would have to integrate all dependencies which *out-of-process-template-haskell* would bring with it. There are now three options discussed on #ghc so far: a) Full integration in ghc, as described above. b) Enabling the plugin interface in stage1 compiler [See Note 1 for details]. This is probably only interesting for cross-compiler, where stage1 is the final stage on the host. [See Note 2 for an example] c) As proposed by luite: integrate a thin layer in ghc, that uses pipes to communicate with an external program on the same host that ghc is running on. That external program will then communicate with the *runner* on the target. The ultimate goal would be a multi-target compiler, that could produce a stage2 compiler that runs on the host but can produce binaries for multiple targets of which the host it's running on is one. I am in favor of extending the plugin api and making it available to stage1 compiler, because I see much potential in the plugin api. Which--with the noted patches [4][5]-- allows you to install hooks, and hence allow you to hook into the complete compiler pipeline and potential other parts as well. It also makes developing plugins easier, because they can be developed outside of the ghc source tree. And only be used with cross compilers if we can load plugins in stage1 compilers. Cheers, Moritz [1]: https://ghc.haskell.org/trac/ghc/wiki/CrossCompilation [2]: https://ghc.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/Stages [3]: https://github.com/angerman/oopth [4]: https://gist.github.com/angerman/7db11c24f8935c73fcf5 [5]: https://phabricator.haskell.org/D535 Note 1: where the plugin will have to be compiled with a stage0 compiler, and may even require a stage0 compiler that is as new as the stage1 compiler one wants to build, because the compiler being built has to be binary compatible with the plugin. Note 2: An example would be building 7.10 on the host for the host with stage0=ghc7.8, stage1=ghc7.10(built with ghc7.8), stage2=ghc7.10(built with stage1), *and then* building a ghc cross compiler for arm with stage0'=stage2 and stage1'(ghc7.10 targeting ARM built with ghc7.10 on the host). And allowing this newly built cross compiler (stage1') to accept -fplugin for plugins built with stage2 (the same that built stage1')

4 3

HEADS UP: I'm removing the remaining .lhs files in compiler/ soon
by Austin Seipp 03 Dec '14

03 Dec '14

Hi *, Quick note: before the branch occurs, me and Herbert really really wanted to remove all the .lhs files in the compiler. We tried to do this as close as possible to the branch to minimize merge headaches, and I've got my tree doing so. This set of patches removes about 100 lhs files in the compiler, across several subsystems. Undoubtly, this will affect some of your work that you're all doing to get into HEAD soon. If you have a currently outstanding branch, a rebase should set you straight; just do: $ git rebase master <mybranch> Git tracks renames for rebases, so it should correctly do most of the work. Nonetheless, you may have some out of date code that has been touched in the mean time (a lot of things have gone through in the past few days), so be sure to be diligent when you rebase it all and whatnot. Thanks -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

RE: new Coercible solver
by Simon Peyton Jones 03 Dec '14

03 Dec '14

| If you have a few minutes, I would love a review of my new Coercible | solver (D546). It seems to be humming along, and it tackles #9117 | nicely. Even better, for me, it will work much more smoothly with my | dependent types branch. I'm eager to get back to that branch, which is | why I'd like to merge this into master soon. A few minutes??!! Hardly. Two hours later... Anyway I've made a start. I assume this is going to land immediately after the 7.10 fork? But it's not entirely obvious: - it is not essential functionality for 7.10 - but it shouldn't mess anything up (or if it does we want to fix it anyway) - and it's a big diff, so *not* putting it in 7.10 will make merging patches to the 7.10 branch harder My instinct is to merge soon (assuming it validates), and let Austin decide whether it makes his life easier to have it or not to have it. Simon | -----Original Message----- | From: Richard Eisenberg [mailto:eir@cis.upenn.edu] | Sent: 02 December 2014 03:15 | To: Simon Peyton Jones | Subject: new Coercible solver | | Hi Simon, | | If you have a few minutes, I would love a review of my new Coercible | solver (D546). It seems to be humming along, and it tackles #9117 | nicely. Even better, for me, it will work much more smoothly with my | dependent types branch. I'm eager to get back to that branch, which is | why I'd like to merge this into master soon. | | Thanks! | Richard | | PS: If you want to Skype, I should be available from about 10am my | time on Tuesday. (Also, possibly available somewhere in the 7am-7:45am | stretch, depending on when Emma wakes up.)

2 1

API Annotations and HsSCC / HsTickPragma
by Alan & Kim Zimmerman 03 Dec '14

03 Dec '14

I am in the process of working the shiny new API annotations through into a practical example in ghc-exactprint [1], but I have hit a snag. A SCC annotation appears in the source as {-# SCC "name" #-} <expression> and if enabled via -prof results in the expression being wrapped in HsSCC FastString (LHsExpr id) BUT, if not enabled, it appears as HsPar (LHsExpr id) >From the parser/annotation point of view, the appropriate annotations are generated, and can be used to distinguish the two cases. The problem is that the annotations only capture the SrcSpan of the thing being annotated, so in the HsPar case the contents of the FastString is lost. A similar situation exists for HsTickPragma, HsTickPragma -- A pragma introduced tick (FastString,(Int,Int),(Int,Int)) -- external span for this tick (LHsExpr id) which also degrades to HsPar I see a number of possible solutions 1. Add the missing information to HsPar in a Maybe HsPar (Maybe (FastString,(Int,Int),(Int,Int))) (LHsExpr id) 2. Modify HsSCC / HsTickPragma to have a Bool indicating whether they are active or not. 3. Introduce an additional annotation type to carry the missing information. I welcome advice on the best way forward. Alan [1] https://github.com/alanz/ghc-exactprint/tree/wip

2 4