- ghc-devs - Haskell.org

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

Arrow notation and GHC 7.10 freeze
by Wolfgang Jeltsch 03 Dec '14

03 Dec '14

Hi, I would like to work on <https://ghc.haskell.org/trac/ghc/ticket/7081>. It would be great if the results of this work could go into GHC 7.10. Is this still possible? When will GHC 7.10 be frozen? All the best, Wolfgang

3 4

New implementation draft for -XStaticPointers
by Facundo Domínguez 02 Dec '14

02 Dec '14

Hello, We are pleased to announce a new implementation draft of the StaticPointers extension [1]. We plan to improve the code still, and probably the interface of GHC.StaticPtr will undergo some changes, but the draft already covers the features that would make us happy to have in ghc 7.10. Looking forward to your comments. Best, Tweag I/O Team [1] https://phabricator.haskell.org/D550

1 0

Re: [commit: ghc] master: Fix the handling of instance signatures (Trac #9582, #9833) (e6a2050)
by Gabor Greif 02 Dec '14

02 Dec '14

Maybe this (https://ghc.haskell.org/trac/ghc/ticket/7908) is fixed too? Cheers, Gabor On 12/1/14, git(a)git.haskell.org <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : > http://ghc.haskell.org/trac/ghc/changeset/e6a2050ebb6da316aecec66a6795715fb… > >>--------------------------------------------------------------- > > commit e6a2050ebb6da316aecec66a6795715fbab355ca > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > Date: Mon Dec 1 11:43:20 2014 +0000 > > Fix the handling of instance signatures (Trac #9582, #9833) > > This finally solves the issue of instance-method signatures that are > more polymorphic than the instanted class method. > > See Note [Instance method signatures] in TcInstDcls. > > A very nice fix for the two Trac tickets above. > > >>--------------------------------------------------------------- > > e6a2050ebb6da316aecec66a6795715fbab355ca > compiler/typecheck/TcBinds.lhs | 18 ++- > compiler/typecheck/TcClassDcl.lhs | 16 +-- > compiler/typecheck/TcInstDcls.lhs | 121 > ++++++++++++--------- > docs/users_guide/glasgow_exts.xml | 29 ++++- > .../tests/indexed-types/should_compile/T9582.hs | 14 +++ > testsuite/tests/indexed-types/should_compile/all.T | 1 + > testsuite/tests/polykinds/T9833.hs | 18 +++ > testsuite/tests/polykinds/all.T | 2 + > testsuite/tests/typecheck/should_fail/T6001.stderr | 9 +- > testsuite/tests/typecheck/should_fail/T7545.hs | 1 + > testsuite/tests/typecheck/should_fail/T7545.stderr | 5 - > testsuite/tests/typecheck/should_fail/all.T | 2 +- > 12 files changed, 157 insertions(+), 79 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder > --ignore-space-at-eol --cc e6a2050ebb6da316aecec66a6795715fbab355ca > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 3

Keeping the "Newcomers" wiki page alive
by Jan Stolarek 02 Dec '14

02 Dec '14

Last year Richard created a wiki page for newcomers: https://ghc.haskell.org/trac/ghc/wiki/Newcomers One of assumptions was to store a list of low hanging fruits that newcomers can tackle: https://ghc.haskell.org/trac/ghc/wiki/Newcomers#Fixingabug But that list is far from exhaustive. Here's where your help is needed. Please remember that this page exists and whenever you report or encounter a simple bug or feature request please add it to the list on Newcomers page. Thanks. Janek

8 14

Possible error with strict_mark in Parser.y
by Alan & Kim Zimmerman 01 Dec '14

01 Dec '14

If I look at the production for strict_mark in the parser https://github.com/ghc/ghc/blob/master/compiler/parser/Parser.y#L1355 strict_mark :: { Located ([AddAnn],HsBang) } : '!' { sL1 $1 ([],HsUserBang Nothing True) } | '{-# UNPACK' '#-}' { sLL $1 $> ([mo $1,mc $2],HsUserBang (Just True) False) } | '{-# NOUNPACK' '#-}' { sLL $1 $> ([mo $1,mc $2],HsUserBang (Just False) True) } -- ***Correct? | '{-# UNPACK' '#-}' '!' { sLL $1 $> ([mo $1,mc $2],HsUserBang (Just True) True) } | '{-# NOUNPACK' '#-}' '!' { sLL $1 $> ([mo $1,mc $2],HsUserBang (Just False) True) } I would expect the final True or False value to reflect the presence of the '!' mark. But the second line has no '!' but returns True. I suspect this is an error. Alan

3 2