May 2017 - ghc-devs - Haskell.org

Default options for -threaded
by lonetiger＠gmail.com 04 Jan '19

04 Jan '19

Hi All, A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why -N -qa isn’t the default for -threaded. I’m afraid I don’t know a good reason why it’s not. Can anyone help shed some light on this? If there is no good reason, Would anyone object to making it the default? Thanks, Tamar

7 10

[ANNOUNCE] GHC 8.2.1 release candidate 1
by Ben Gamari 03 Oct '17

03 Oct '17

Hello everyone, The GHC team is very pleased to announce the first candidate of the 8.2.1 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.1-rc1/ This is the first of a few release candidates leading up the final 8.2.1 release. This release will feature, * A new type-indexed Typeable implementation * The long awaited Backpack * Deriving strategies for disambiguating DeriveAnyClass, GeneralizedNewtypeDeriving, and stock mechanisms * Overloaded record fields * Improved compiler performance * Better code generation through more robust tracking of join points * Compact regions for more efficient garbage collection and serialization * Better support for machines with non-uniform memory architectures * More robust support for levity (e.g. RuntimeRep) polymorphism * A simple interface for streaming eventlog data from live processes * Further refinement of DWARF support Unfortunately there are still a few known issues in this release, including a few compiler panics (#13233, #13509) and a memory leak in the simplifier (#13426) which may adversely affect heap sizes and compilation time for some modules. This memory leak unfortunately made it impossible to provide a 32-bit Windows distribution for this candidate; this will be resolved in -rc2. As always, please let us know if you have difficulty. Thanks to everyone who has contributed to this release! Happy testing, - Ben

5 15

can't validate on Linux
by Richard Eisenberg 09 Jul '17

09 Jul '17

Hi devs, When I try validating my patch, validation fails with > ... > Registering library for ghc-prim-0.5.0.0.. > ghc-cabal: '/home/rae/ghc/ghc-valid/bindisttest/install > dir/lib/ghc-8.3.20170312/bin/ghc-pkg' exited with an error: > ghc-pkg: Couldn't open database /home/rae/ghc/ghc-valid/bindisttest/install > dir/lib/ghc-8.3.20170312/package.conf.d for modification: {handle: > /home/rae/ghc/ghc-valid/bindisttest/install > dir/lib/ghc-8.3.20170312/package.conf.d/package.cache.lock}: hLock: invalid > argument (Bad file descriptor) > make[3]: *** [ghc.mk:990: install_packages] Error 1 > make[2]: *** [Makefile:51: install] Error 2 > make[1]: *** [bindisttest/ghc.mk:33: test_bindist] Error 2 > make: *** [Makefile:127: test_bindist] Error 2 Any advice? Thanks! Richard

5 7

Haskell Implementors' Workshop Call for Talks
by Richard Eisenberg 04 Jul '17

04 Jul '17

Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://icfp17.sigplan.org/track/hiw-2017 Oxford, UK, 9 September, 2017 Co-located with ICFP 2017 http://www.icfpconference.org/icfp2017/ Important dates --------------- Proposal Deadline: Thursday, 6 July, 2017 Notification: Thursday, 20 July, 2017 Workshop: Saturday, 9 September, 2017 The 9th Haskell Implementors' Workshop is to be held alongside ICFP 2017 this year in Oxford. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2017. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw17.hotcrp.com/ We will also have a lightning talks session which will be organised on the day. These talks will be 5-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Program Committee ----------------- * Richard A. Eisenberg -- chair (Bryn Mawr College) * Adam Gundry (Well-Typed) * Bartosz Nitka (Facebook) * Wren Romano (X, formerly Google[x]) * Alejandro Serrano Mena (Utrecht University) * Jan Stolarek (University of Edinburgh) Contact ------- * Richard A. Eisenberg <rae(a)cs.brynmawr.edu>

1 1

Removing Hoopl dependency?
by Michal Terepeta 12 Jun '17

12 Jun '17

Hi all, I was looking at removing the `BlockId` type synonym in favor of Hoopl's `Label` (there was already a TODO and it is a bit confusing). But once I've started making the changes, I've realized that in a bunch of places this makes the code *less* readable. Mostly because of `CLabel` (sounds similar but is something quite different and having to rename local variables from `label` to `clabel` is not great). I started to look at alternatives and noticed that in general the interface between GHC and Hoopl is quite noisy and confusing: - Hoopl has `Label` which is GHC's `BlockId` but different than GHC's `CLabel` - Hoopl has `Unique` which is different than GHC's `Unique` - Hoopl has `Unique{Map,Set}` which are different than GHC's `Uniq{FM,Set}` - GHC has its own specialized copy of `Dataflow`, so `cmm/Hoopl` is needed just to filter the exposed functions (filter out some of the Hoopl's and add the GHC ones). - Working in `cmm/` requires constant switching between GHC code and Hoopl (`CmmNode`/`CmmGraph`/`CmmBlock` and dataflow stuff is in GHC, the actual implementation of `Block`/`Graph` are defined in Hoopl, etc.) GHC is actually using only a small subset of Hoopl (e.g., the fixpoint computation is copied/specialized: `cmm/Hoopl/Dataflow`). So I was wondering - maybe it's worth to simply drop the dependency on Hoopl? (and copy the code that is actually necessary in GHC) I've done an experiment in [1] (to see how much we'd need to actually copy) and I really like the result: - We can remove one external dependency and git submodule at the cost of only 5 new modules in `cmm/Hoopl` (net gain of only 4 modules: we add 5 new but can remove `cmm/Hoopl`, which is no longer needed) - We should be able to fix all of the above issues and make the code easier to understand (less code, everything in one repo, fewer concepts). - It's going to be easier to change things since we don't need to worry about changing the public interface of Hoopl (it's a standalone package on Hackage and other people already depend on the current behavior). What do you think? Does anyone think we shouldn't do this? Thanks, Michal [1] Branch: https://github.com/michalt/ghc/tree/hoopl/no-hoopl Diff: https://github.com/ghc/ghc/compare/master...michalt:hoopl/no-hoopl For now I just copied the code/updated imports and didn't do any cleanups, but I'd be happy to do them in subsequent PRs

8 22

Hunting down a compilation performance regression involving type families
by Ryan Scott 06 Jun '17

06 Jun '17

Richard, In an effort to figure out why programs with lots of type families have become so much slower over the last few GHC releases, I've been looking at GHC Trac #12545 [1], which provides a very self-contained test case that became considerably slower to compile from GHC 7.10 to 8.0. Thanks to this test case, I found one of the sources of the slowdown: a single, very small commit of yours [2]. What's baffling, though, is that I can't figure out why that commit makes compilation so much slower. I tried making profiled builds of GHC before and after that commit and attaching SCCs to the new code, but to my surprise, their contribution to the overall compilation time was negligible. So I'm out of ideas on what might be causing this. The only hint I have is the output of -ddump-simpl-stats/-dshow-passes. Before that commit, there's a point where the terms, types, and coercions go up: *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 20,769, types: 1,157,897, coercions: 3,635,961} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 44,081, types: 2,451,155, coercions: 9,802,016} But after that commit, the terms and types jump up considerably higher! *** Simplifier: Result size of Simplifier = {terms: 16,429, types: 864,761, coercions: 2,184,448} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 87,357, types: 4,366,893, coercions: 10,008,352} Here are the relevant bits from -ddump-simpl-stats. Before that commit: 150 PreInlineUnconditionally 40 PostInlineUnconditionally 220 UnfoldingDone 110 RuleFired 380 BetaReduction After that commit: 306 PreInlineUnconditionally 160 PostInlineUnconditionally 360 UnfoldingDone 308 RuleFired 1238 BetaReduction Does you know what might be going on here? Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/12545 [2] https://ghc.haskell.org/trac/ghc/changeset/1722fa106e10e63160bb2322e2ccb830…

2 2

RE: Trees that Grow in the hsSyn AST
by Simon Peyton Jones 01 Jun '17

01 Jun '17

1. Which is better to start with: HsSyn or Core? Intuition suggests this sort of thing could be very helpful for making zapping more reliable and ensuring its efficiency, but there may be better reasons to start with HsSyn. Definitely HsSyn. It’s big, riddled with extra info, and has many purposes for different people. Core is small, tight, nailed down. I don’t want to mess with it. 2. If we're making intrusive changes to representations, would now be a sensible era to consider switching to a different variable representation (unbound, bound, abt, etc)? I don’t think so. The issues are quite orthogonal, and no one (to my knowledge) has proposed any vaguely plausible change to variable bindings that would scale to what GHC does. In contrast, this stuff is “just” re-engineering. Simon From: David Feuer [mailto:david@well-typed.com] Sent: 26 May 2017 01:11 To: Simon Peyton Jones <simonpj(a)microsoft.com>; Alan & Kim Zimmerman <alan.zimm(a)gmail.com>; ghc-devs(a)haskell.org Subject: RE: Trees that Grow in the hsSyn AST I haven't looked in detail yet, but there seem to be good ideas. I have two questions: 1. Which is better to start with: HsSyn or Core? Intuition suggests this sort of thing could be very helpful for making zapping more reliable and ensuring its efficiency, but there may be better reasons to start with HsSyn. 2. If we're making intrusive changes to representations, would now be a sensible era to consider switching to a different variable representation (unbound, bound, abt, etc)? David Feuer Well-Typed, LLP -------- Original message -------- From: Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> Date: 5/25/17 6:48 PM (GMT-05:00) To: Alan & Kim Zimmerman <alan.zimm(a)gmail.com<mailto:alan.zimm@gmail.com>>, ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: RE: Trees that Grow in the hsSyn AST Folks Do take a look at this: · We propose to re-engineer HsSyn itself. This will touch a lot of code. · But it’s very neat, and will bring big long-term advantages · And we can do it a bit at a time The wiki page https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow has the details. It’s entirely an internal change, not a change to GHC’s specification, so it’s independent of the GHC proposals process. But I’d value the opinion of other GHC devs. Alan has done a prototype first step, which worked out rather well. Rather than having HsExpr Id (which we all know means “HsExpr after the typechecker” but tha’s a bit inexplicit, we have HsExpr GhcTc meaning “HsExpr after GHC’s Tc pass”. In some ways this is quite superficial, but it unlocks the Trees That Grow machiney. Please ask questions etc. Alan and Shayan can record the answers in the wiki. I’m inclined to go ahead with this, so yell soon if you disagree. Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 24 May 2017 22:52 To: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: Trees that Grow in the hsSyn AST Hi all You may be aware that Shayan Najd presented the paper "Trees that Grow"[1] at HIW last year. Based on the following mandate > As in my previous email to Shayan (attached). Wiki page, describe goals, design, > approach. Point to prototype implementation. Seek comments. You can say that >I am supportive! > > Simon We have set up a Wiki page at [2] describing a prototype implementation of the first stage of this for the hsSyn AST, which is to change the polymorphic variable from one of RdrName / Name / Id to an index type. This is presented as a fabricator diff at [3]. Please take a look and provide feedback. Regards Alan [1] http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jucs.or…<http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf…>> [2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow [3] https://phabricator.haskell.org/D3609

2 2

Cross-compiling Template Haskell via -fexternal-interpreter and IPC
by Alberto Valverde 30 May '17

30 May '17

Hello, I'm trying to put together a GHC 8.0.1 cross-compiler with Template Haskell support. Initially to target Windows (32bits) from a Linux host but a similar procedure should enable to target other platforms too. I'd like to contribute the patches back so I'm asking for advice on how to implement it in order to increase the chances of them being accepted. I've managed to get a working stage 1 cross-compiler with some patches which correctly builds all stage1 libs and GHC + stage 2 compiler and ghc-iserv.exe. However, compiling TH by using wine and ghc-iserver.exe fails because the file descriptor ids that GHC passes as arguments to "wine ghc-iserv.exe" don't make sense in the emulated windows world. I've hacked around this to test the feasibility of the approach by using stdin/stdout instead of creating new pipes and, surprisingly, managed to cross-compile a simple Template Haskell program. I'm considering using a socket for communicating between both processes as a more permanent solution but this would incur in a dependency on the "network" package. Would this be acceptable? Named pipes have also crossed my mind but I'm not sure how well they're supported by wine. Thanks for your attention. Alberto P.S: Code is in the "cross-mingw-hacks" branches of these repositories and is based on the ghc-8.0.1-release tag: https://github.com/albertov/ghc https://github.com/albertov/hsc2hs A Docker image script here that builds it is here: https://github.com/albertov/ghc-cross-compiler-windows-x86

6 11

Finding out if a binding is externally visible
by Sebastian Graf 29 May '17

29 May '17

Hi all, I'm tinkering around with GHCs Call Arity Analysis and Demand Analysis as part of my Master's thesis. The usage analysis part is what I'm interested in in particular. After quite some time spent debugging absent errors, I noticed that certain top-level bindings aren't exported, but still visible in other modules through generated RULE pragmas (e.g. through class instance specialization). These bindings were considered absent in my combined analysis, explaining the very sporadic absent errors I was getting. Is there some function that tells me if an identifier is 'externally visible' in that sense? I think https://downloads.haskell.org/~ghc/8.0.1/docs/html/libraries/ghc-8.0.1/GHC.… is what I'm after, but I want to be sure. Does that function already work when the Ids are still local? Greetings, Sebastian

2 8

RE: [commit: ghc] master: Fix test output after 'Some tidying up of type pretty-printing' (09d5c99)
by Simon Peyton Jones 28 May '17

28 May '17

Sorry about this. I carefully fixed all these and validated...thanks for fixing Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 27 May 2017 15:45 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Fix test output after 'Some tidying up of | type pretty-printing' (09d5c99) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske | ll.org%2Ftrac%2Fghc%2Fchangeset%2F09d5c993aae208e3d34a9e715297922b6ea42b3 | f%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2a237b8dabd42f3684f08d4 | a50ef9ad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636314931129891311& | sdata=VM04DE0U1RBSmJjbV6vCwu8LPvyqwqfo2K1I03W1cW4%3D&reserved=0 | | >--------------------------------------------------------------- | | commit 09d5c993aae208e3d34a9e715297922b6ea42b3f | Author: Bartosz Nitka <niteria(a)gmail.com> | Date: Sat May 27 07:42:26 2017 -0700 | | Fix test output after 'Some tidying up of type pretty-printing' | | Most are cosmetic. There's an interesting change in T7861, | but the error is still accurate. | | | >--------------------------------------------------------------- | | 09d5c993aae208e3d34a9e715297922b6ea42b3f | testsuite/tests/typecheck/should_run/T7861.stderr | 6 +----- | testsuite/tests/typecheck/should_run/Typeable1.stderr | 2 +- | testsuite/tests/typecheck/should_run/tcrun045.stderr | 6 +++--- | 3 files changed, 5 insertions(+), 9 deletions(-) | | diff --git a/testsuite/tests/typecheck/should_run/T7861.stderr | b/testsuite/tests/typecheck/should_run/T7861.stderr | index e9ee5e9..4a1c030 100644 | --- a/testsuite/tests/typecheck/should_run/T7861.stderr | +++ b/testsuite/tests/typecheck/should_run/T7861.stderr | @@ -1,9 +1,5 @@ | T7861: T7861.hs:10:5: error: | - • Couldn't match type ‘a’ with ‘[a]’ | - ‘a’ is a rigid type variable bound by | - the type signature for: | - f :: forall a. (forall b. a) -> a | - at T7861.hs:9:1-23 | + • Occurs check: cannot construct the infinite type: a ~ [a] | Expected type: (forall b. a) -> a | Actual type: (forall b. a) -> [a] | • In the expression: doA | diff --git a/testsuite/tests/typecheck/should_run/Typeable1.stderr | b/testsuite/tests/typecheck/should_run/Typeable1.stderr | index 9a7d3b7..65f6fd4 100644 | --- a/testsuite/tests/typecheck/should_run/Typeable1.stderr | +++ b/testsuite/tests/typecheck/should_run/Typeable1.stderr | @@ -7,7 +7,7 @@ Typeable1.hs:22:5: error: | App :: forall k2 (t :: k2). | () => | forall k1 (a :: k1 -> k2) (b :: k1). | - t ~ a b => | + (t ~ a b) => | TypeRep a -> TypeRep b -> TypeRep t, | in a pattern binding in | 'do' block | diff --git a/testsuite/tests/typecheck/should_run/tcrun045.stderr | b/testsuite/tests/typecheck/should_run/tcrun045.stderr | index 19fca10..f6b1652 100644 | --- a/testsuite/tests/typecheck/should_run/tcrun045.stderr | +++ b/testsuite/tests/typecheck/should_run/tcrun045.stderr | @@ -1,18 +1,18 @@ | | tcrun045.hs:11:10: error: | • Illegal implicit parameter ‘?imp::Int’ | - • In the context: (?imp::Int) | + • In the context: ?imp::Int | While checking an instance declaration | In the instance declaration for ‘C Int’ | | tcrun045.hs:24:1: error: | • Illegal implicit parameter ‘?imp::Int’ | - • In the context: (?imp::Int) | + • In the context: ?imp::Int | While checking the super-classes of class ‘D’ | In the class declaration for ‘D’ | | tcrun045.hs:27:10: error: | • Illegal implicit parameter ‘?imp::Int’ | - • In the context: (?imp::Int) | + • In the context: ?imp::Int | While checking an instance declaration | In the instance declaration for ‘D Int’ | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2a237b8dabd42f3684f08d4 | a50ef9ad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636314931129891311& | sdata=MYdcDMAQcDnFVFlc0aNT1NXPHFa%2FT%2FSpNiDIu4hrvOY%3D&reserved=0

1 0