- ghc-devs - Haskell.org

Someone please delete my Trac report
by Simon Jakobi 03 Mar '18

03 Mar '18

Hi! Could someone with the appropriate permissions please delete report #26 "Interesting" at https://ghc.haskell.org/trac/ghc/report? When I saved my query I didn't expect that it would be visible to everyone. Cheers, Simon

2 1

Guarded Impredicativity implementation
by Artem Pelenitsyn 02 Mar '18

02 Mar '18

Dear ghc-devs, Is there any work has been done on the latest (ttbomk) proposal for impredicative types in Haskell: > Guarded impredicative polymorphism by Alejandro Serrano, Jurriaan Hage, Dimitrios Vytiniotis, Simon Peyton Jones https://www.microsoft.com/en-us/research/wp-content/uploads/2017/07/impredi… Or are there any plans to do so? I wasn't able to spot any mentions of this in either of GHC's forums (this list, Trac, wiki, ghc-proposals repo). -- Best wishes, Artem Pelenitsyn

3 2

An idea for a different style of metaprogramming evaluation using the optimiser
by Matthew Pickering 28 Feb '18

28 Feb '18

I've had an idea for a while of a different way we could evaluate TH-like splices which would be more lightweight and easier to work with. The idea is to create a third quotation/splicing mechanism which has no introspection (like MetaML) but then to evaluate these quotes and splices in the optimiser rather than using the bytecode interpreter. I am motivated by the many examples of recursive functions in libraries, which when given a statically known argument should be able to be unrolled to produce much better code. It is understandable that the compiler doesn't try to do this itself but there should be an easy way for the user to direct the compiler to do so. (See also https://www.reddit.com/r/haskell/comments/7yvb43/ghc_compiletime_evaluation/) An example to be concrete: Take the power function such that power k n computes k^n. power :: Int -> Int -> Int power k n = if n == 0 then 1 else k * power k (n - 1) If we statically know n then we can create a staged version. We use R to indicate that an argument is dynamically known. power :: R Int -> Int -> R Int power k n = if n == 0 then .< 1 >. else .< ~k * ~(power k (n-1)) >. One way to implement this in Haskell is to use typed template haskell quoting and splicing. The key thing to notice about why this works is that in order to splice `power k (n-1)` we need to evaluate `power k (n-1)` so that we have something of type `R Int` which we can then splice back into the quote. The way this is currently implemented is that the bytecode interpreter runs these splices in order to find out what they evaluate to. The idea is that instead, we add another mode which runs splices in the core-to-core optimiser. The optimiser performs evaluation by beta reduction, inlining and constant folding. For simple definitions on algebraic data types it does a very good job of eliminating overhead. As long as the call is not recursive. If we can just get the optimiser to inline recursive calls in a controlled manner as well, it should do a good job on the unrolled definition. The benefits of this are that it works across all platforms and fits nicely already into the compilation pipeline. It also fits in nicely with the intuition that a "quote" means to stop evaluating and a "splice" means to evaluate. A disadvantage is that the optimiser is only a *partial* evaluator rather than an evaluator. It gets stuck evaluating things containing primitives and so on. I don't forsee this as a major issue but a limitation that library authors should be aware of when writing their staged programs. To go back to the power example, the recursive condition would have to be an inductively defined natural (data N = Z | S N) rather than an Int as the comparison operator for integers can't be evaluated by the optimiser. It is already rather easy to write staged programs which loop if you don't carefully consider the staging so this seems now worse than the status quo. Does this sound at all sensible to anyone else? Matt

3 4

Help with build ordering issue
by Sylvain Henry 26 Feb '18

26 Feb '18

Hi, @Bodigrim is working on a patch (https://phabricator.haskell.org/D4212) to fix #14170. The build fails because of interface file errors: "bad interface file" for GHC.Natural and "failed to load interface" for GHC.Types. I suspect it is a wired-in module build ordering issue but I haven't been able to help fixing it. If anyone with more insights could help it would be much appreciated! Thanks, Sylvain

2 6

RE: [commit: ghc] master: testsuite: Bump allocations for T9630 (f57c305)
by Simon Peyton Jones 26 Feb '18

26 Feb '18

This is a reduction => good! "Bump" is usually bad. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 25 February 2018 21:58 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: testsuite: Bump allocations for T9630 | (f57c305) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha | skell.org%2Ftrac%2Fghc%2Fchangeset%2Ff57c3059d7c8b8e00bd3a9f9153c3520f | 6db14d4%2Fghc&data=04%7C01%7Csimonpj%40microsoft.com%7Cbff75d8952bc489 | 7f12608d57c9ae8c0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365519 | 27127060212%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwifQ%3D%3D%7C- | 1&sdata=Hk8Q%2FVgrwqEUkysgX3Stj5GO5t3YNeM04wALzV6ZZSE%3D&reserved=0 | | >--------------------------------------------------------------- | | commit f57c3059d7c8b8e00bd3a9f9153c3520f6db14d4 | Author: Ben Gamari <ben(a)smart-cactus.org> | Date: Sun Feb 25 16:23:39 2018 -0500 | | testsuite: Bump allocations for T9630 | | | >--------------------------------------------------------------- | | f57c3059d7c8b8e00bd3a9f9153c3520f6db14d4 | testsuite/tests/perf/compiler/all.T | 3 ++- | 1 file changed, 2 insertions(+), 1 deletion(-) | | diff --git a/testsuite/tests/perf/compiler/all.T | b/testsuite/tests/perf/compiler/all.T | index 1ae69e7..1a2413a 100644 | --- a/testsuite/tests/perf/compiler/all.T | +++ b/testsuite/tests/perf/compiler/all.T | @@ -1228,9 +1228,10 @@ test ('T9630', | [ compiler_stats_num_field('max_bytes_used', # Note [residency] | [(platform('x86_64-unknown-mingw32'), 39867088, 15), | # 2017-12-24: 34171816 (x64/Windows) | - (wordsize(64), 41568168, 15) | + (wordsize(64), 35324712, 15) | # initial: 56955240 | # 2017-06-07: 41568168 Stop the specialiser generating | loopy code | + # 2018-02-25: 35324712 It's not entirely clear | ]), | extra_clean(['T9630a.hi', 'T9630a.o']) | ], | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=04%7C01%7Csimonpj%40microsoft.com%7Cbff75d8952bc4897f1260 | 8d57c9ae8c0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365519271270 | 60212%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB | TiI6Ik1haWwifQ%3D%3D%7C- | 1&sdata=2bTG4reUJV7m3RsSUMse20LChfZPcJP3Ea%2FQkgqmLFw%3D&reserved=0

2 1

GNU make file in ghc/utils folder
by Chris R. Timmons 23 Feb '18

23 Feb '18

I'm trying to add a new utility to the $(TOP)/ghc/utils folder. The utility has a make file, but I can't seem to get it to play nice with GHC's build system. The error I receive is "No rule to make target...". Here's a simple test environment that demonstrates the problem: --------------- 1. Create a new folder called $(TOP)/ghc/utils/testmake. 2. In the 'testmake' folder, create a file named "Makefile" with this content: dir = utils/testmake TOP = ../.. include $(TOP)/mk/sub-makefile.mk 3. In the 'testmake' folder, create a file named "ghc.mk" with this content (NOTE: My email app may have replaced the tab character before "@echo" with spaces.): $(eval $(call all-target,utils/testmake,utils/testmake/dummy_target)) utils/testmake/dummy_target: @echo Hello world! ---------------- Running make results in a "No rule to make target" error: $ make make -C ../.. all_utils/testmake make[1]: Entering directory '/home/ctimmons/ghc' ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[2]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds make[2]: Nothing to be done for 'phase_1_builds'. ===--- building final phase make --no-print-directory -f ghc.mk phase=final all_utils/testmake make[2]: *** No rule to make target 'all_utils/testmake'. Stop. make[1]: *** [Makefile:127: all_utils/testmake] Error 2 make[1]: Leaving directory '/home/ctimmons/ghc' make: *** [../../mk/sub-makefile.mk:50: all] Error 2 However, running ghc.mk directly from the utils/testmake folder does not result in an error: $ make -C ../.. -f utils/testmake/ghc.mk make: Entering directory '/home/ctimmons/ghc' Hello world! make: Leaving directory '/home/ctimmons/ghc' What am I not understanding? Thanks. Chris

2 2

DoAndIfThenElse
by Harendra Kumar 22 Feb '18

22 Feb '18

Hi, I recently found a mention of DoAndIfThenElse extension somewhere. I looked inside the ghc user guide and could not find any such extension. Then I looked in the ghc man page, no mention. I googled and found a very sparse references to it here and there. Then I tried using the extension with ghc and ghc seems to accept it. What's the story behind this, why is it not documented but accepted? thanks, harendra

5 6

A (late-)demand analysis and w/w question
by Ömer Sinan Ağacan 21 Feb '18

21 Feb '18

Hi, I was recently looking at #6087. One of the cases that increased allocations (see comment:27) is when we do worker/wrapper to pass an `Int#` instead of `Int` when we need the boxed form in the function body. This causes redundant allocations because we already have the boxed version of the value but we passed it unboxed as a result of worker/wrapper. This raises the obvious (but maybe naive?) question of whether we could improve the demand analysis and/or worker/wrapper to avoid unpacking arguments when the argument is boxed again somewhere in the function body. Does this make sense? Has anyone tried this before? Thanks, Ömer

2 3

Re: [GHC DevOps Group] Release policies
by Boespflug, Mathieu 19 Feb '18

19 Feb '18

Hi Herbert, On 18 December 2017 at 12:22, Herbert Valerio Riedel <hvriedel(a)gmail.com> wrote: > Hi Mathieu, > > On Mon, Dec 18, 2017 at 12:03 PM, Boespflug, Mathieu <m(a)tweag.io> wrote: >> it's worth thinking about asking that >> the versions of all upstream packages only make it into GHC, at the >> behest of their respective maintainers, after a new release of >> upstream is made. > > Let me try to formulate the invariant such a procedure would demand: > > That would require a guarantee that the APIs provided by GHC (mostly > ghc-prim/base, but possibly more, including other boot libs; as well > as GHC's own behaviour) my package(s) rely upon are frozen to the > point that any such release of my packages advertising compatiblity > with the imminent GHC release will remain compatible with said final > GHC release. > > Is this something you're ready to guarantee? That's exactly it: a tradeoff. As you note, any package release now can't possibly anticipate all changes in future GHC. Furthermore, if a new GHC feature crucially depends on upstream but no upstream release is available yet, under this proposal merging the new GHC feature would need to be delayed. But on the other hand, if indeed GHC is to have more frequent releases, we can't have a GHC release perennially held up by upstream maintainers cutting their own releases one after the other, or worse still, releases happening *after* it already shipped in GHC as we just saw, or with breaking changes not announced to downstream tooling authors ahead of time. This is a problem that was brought up by Ben at ICFP, and again here. It's a problem relevant to the discussion at hand, which started as the result of upstream releases showing up on Hackage long after the release, and downstream tooling authors not afforded any advance notice to adapt. When this was brought up at ICFP, several GHC DevOps Group members recommended to Ben that he avoid needing *any* cooperation from upstream maintainers on the critical path towards a release. Of the packages you mention, base can't introduce breaking changes without a grace period. Are any upstream packages that closely tied to ghc-prim etc that a breaking change in the latter is likely between feature freeze and the release date? On the off-chance that a BC change does happen, package releases are cheap, so would that really be a problem? If a package is that closely tied to ghc-prim, base or any other boot lib, and conversely GHC is closely tied to it, then shouldn't that package just be part of the GHC codebase proper, rather than managed separately outside of GHC devs' control?

6 9

testsuite failures in DEBUG
by Richard Eisenberg 14 Feb '18

14 Feb '18

Hi devs, It seems our CI infrastructure has become too good. My workflow normally involves working with a DEBUG compiler, and then occasionally running the whole testsuite. I don't validate from scratch mid-patch, but it's good to know if I'm failing tests. With HEAD, I'm getting quite a few testsuite failures, and they all seem to be coming from ASSERTs, and they're all problems that I'm pretty sure I didn't cause. My full list of failures (I'm on Mac) is below, but after looking into 5-6 of them and finding only stuff that isn't my fault, I've given up. So: would it be possible to have our CI infrastructure validate DEBUG mode as well? Then it would be easy to spot where these failures are from. backpack/cabal/bkpcabal02/bkpcabal02.run bkpcabal02 [bad stderr] (normal) backpack/cabal/bkpcabal04/bkpcabal04.run bkpcabal04 [bad stderr] (normal) backpack/cabal/bkpcabal03/bkpcabal03.run bkpcabal03 [bad stderr] (normal) backpack/cabal/bkpcabal05/bkpcabal05.run bkpcabal05 [bad stderr] (normal) backpack/cabal/T14304/T14304.run T14304 [bad stderr] (normal) backpack/cabal/bkpcabal06/bkpcabal06.run bkpcabal06 [bad stderr] (normal) backpack/cabal/bkpcabal07/bkpcabal07.run bkpcabal07 [bad stderr] (normal) backpack/cabal/bkpcabal01/bkpcabal01.run bkpcabal01 [bad stderr] (normal) cabal/cabal04/cabal04.run cabal04 [bad stderr] (normal) cabal/T12733/T12733.run T12733 [bad stderr] (normal) cabal/cabal01/cabal01.run cabal01 [bad stderr] (normal) cabal/cabal03/cabal03.run cabal03 [bad stderr] (normal) cabal/cabal09/cabal09.run cabal09 [bad stderr] (normal) cabal/cabal08/cabal08.run cabal08 [bad stderr] (normal) cabal/cabal05/cabal05.run cabal05 [bad stderr] (normal) cabal/cabal06/cabal06.run cabal06 [bad stderr] (normal) dependent/should_compile/T12442.run T12442 [exit code non-0] (normal) dependent/should_compile/T12176.run T12176 [exit code non-0] (normal) driver/T3007/T3007.run T3007 [bad stderr] (normal) gadt/T12087.run T12087 [stderr mismatch] (normal) ghci/scripts/ghci063.run ghci063 [bad stderr] (ghci) indexed-types/should_fail/T13877.run T13877 [stderr mismatch] (normal) parser/should_fail/NumericUnderscoresFail0.run NumericUnderscoresFail0 [stderr mismatch] (normal) parser/should_fail/NumericUnderscoresFail1.run NumericUnderscoresFail1 [stderr mismatch] (normal) patsyn/should_compile/T13350/T13350.run T13350 [bad stderr] (normal) pmcheck/should_compile/T11195.run T11195 [exit code non-0] (normal) polykinds/T14174a.run T14174a [exit code non-0] (normal) printer/T13050p.run T13050p [bad exit code] (normal) safeHaskell/check/pkg01/safePkg01.run safePkg01 [bad stderr] (normal) simplCore/should_compile/T13025.run T13025 [bad stderr] (normal) simplCore/should_compile/T13410.run T13410 [exit code non-0] (normal) typecheck/T13168/T13168.run T13168 [bad stderr] (normal) typecheck/bug1465/bug1465.run bug1465 [bad stderr] (normal) typecheck/should_compile/holes2.run holes2 [exit code non-0] (normal) typecheck/should_compile/valid_substitutions.run valid_substitutions [exit code non-0] (normal) typecheck/should_compile/holes3.run holes3 [stderr mismatch] (normal) typecheck/should_compile/holes.run holes [stderr mismatch] (normal) typecheck/should_compile/T13050.run T13050 [exit code non-0] (normal) typecheck/should_compile/T13822.run T13822 [exit code non-0] (normal) typecheck/should_compile/T14590.run T14590 [exit code non-0] (normal) typecheck/should_compile/T13032.run T13032 [stderr mismatch] (normal) typecheck/should_fail/T7175.run T7175 [stderr mismatch] (normal) Thanks! Richard

3 3