- ghc-devs - Haskell.org

8.2.1 Status
by Ben Gamari 12 Jun '17

12 Jun '17

Hello everyone, GHC 8.2.1 release candidate 2 has been out for a few weeks now and, while it turned up a number of issues, it seems that the release is (slowly) solidifying. Currently the ghc-8.2 branch has nearly 50 commits since the -rc2 tag, fixing many of the issues that have been reported. While we were hoping that 8.2 would require only two release candidates, it seems pretty clear that a third is in order. At this point, there are still a few more tickets in need of resolution before -rc3 release candidate can be cut. Hopefully these will be sorted out in the coming week, which means that we can cut a new source release by mid-next week, with the binary releases coming a week later. Unfortunately this all means that we'll realistically be looking at a 8.2.1 release date sometime near the beginning of July. As always, help is greatly appreciated; drop by #ghc if you would like to help squash some bugs. Cheers, - Ben

1 0

More TRAC ticket statuses?
by David Feuer 08 Jun '17

08 Jun '17

There are (at least) two situations that I don't think we currently have a good way to track: 1. A new bug has been verified, but we do not yet have an expect_broken test case. 2. A bug has been fixed, but we are waiting for a test case. Lacking (1) means that we have to manually dig through the ticket database and try things out in order to knock down tickets that should have already been closed. Lacking (2) means that a ticket could potentially get stuck in "new" status after someone's already done practically all the work required to fix them. What should we do about this? David

2 1

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

06 Jun '17

Ah yes, I believe you're referring to https://ghc.haskell.org/ trac/ghc/ticket/8767 (which I wasn't aware of). And yes, I do believe we'd need some combination of QuantifiedContexts/ImplicationConstraints to fully support everything. But in any case, don't let this discussion side-track too much from the matter at hand (the type family compilation slowdown). My suggestion _was_ somewhat tongue-in-cheek, after all ;) Ryan S. On Tue, Jun 6, 2017 at 11:01 AM, David Feuer <david(a)well-typed.com> wrote: > Edward Kmett has explained that this isn't sufficient when things go > higher order. His suggested improvement is > > liftCoercion :: Maybe (Coercion a b -> Coercion (f a) (f b)) > > > > David Feuer > Well-Typed, LLP > > -------- Original message -------- > From: Ryan Scott <ryan.gl.scott(a)gmail.com> > Date: 6/6/17 1:41 PM (GMT-05:00) > To: Richard Eisenberg <rae(a)cs.brynmawr.edu> > Cc: GHC developers <ghc-devs(a)haskell.org>, Eric Mertens < > emertens(a)gmail.com> > Subject: Re: Hunting down a compilation performance regression involving > type families > > Hrm. It's a shame that supporting this map/coerce RULE causes such pain. > > This makes me wonder: can we get rid of this RULE? Eric Mertens pointed out > a trick [1] that's used in the profunctors library to make mapping coerce > over certain Profunctors more efficient. To adapt this trick for Functor, > we'd need to add another class method: > > class Functor f where > fmap :: (a -> b) -> f a -> f b > (<#>) :: Coercible a b => (a -> b) -> f a -> f b > (<#>) = \f -> \p -> p `seq` fmap f p > > Now, when implementing Functor instances, if we are working with a datatype > whose role is representational or phantom, we can make (<#>) really fast: > > data List a = Nil | Cons a (List a) > instance Functor List where > fmap = ... > (<#>) = coerce > > Now, instead of relying on (map MkNewtype Nil) to rewrite to Nil, we can > just use (MkNewtype <#> Nil)! No map/coerce RULE necessary :) > > OK, I realize that suggesting that we remove the RULE is perhaps a touch > too far. But it does sting that we have to pay hefty compilation penalties > because of its existence... > > Ryan S. > ----- > [1] > http://hackage.haskell.org/package/profunctors-5.2/docs/ > Data-Profunctor-Unsafe.html#v:-35- > . > > On Wed, May 31, 2017 at 7:25 PM, Richard Eisenberg <rae(a)cs.brynmawr.edu> > wrote: > > > > > > On May 31, 2017, at 5:21 PM, Ryan Scott <ryan.gl.scott(a)gmail.com> > wrote: > > > Does you know what might be going on here? > > > > I think so, but I don't know how to fix it. > > > > The commit you found (thank you!) makes simple_opt_expr (the "simple > > optimizer", run directly after desugaring, even with -O0) a little more > > selective in what `case` expressions it throws away. Previous to that > > commit, the optimizer would throw away a `case error "deferred type > error" > > of _ -> ...` which is terrible. It seems that you have discovered that we > > are now too timid in throwing away unhelpful cases. It would be > interesting > > to know what the newly-retained cases look like, so that we might throw > > them away. > > > > But there remains a mystery: Why do we need this code at all? Reading > Note > > [Getting the map/coerce RULE to work] closely, it seems we need to > simplify > > > > forall a b (co :: a ~R# b). > > let dict = MkCoercible @* @a @b co in > > case Coercible_SCSel @* @a @b dict of > > _ [Dead] -> map @a @b (\(x :: a) -> case dict of > > MkCoercible (co :: a ~R# b) -> x |> co) = let dict = ... in ... > > > > to > > > > forall a b (co :: a ~R# b). > > map @a @b (\(x :: a) -> x |> co) = \(x :: [a]) -> x |> [co] > > > > Part of doing so is to drop the `case Coercible_SCSel ...`, which gets in > > the way. The mystery is why this needs special code -- shouldn't the > > eliminate-case-of-known-constructor do the trick? This would require > > unfolding Coercible_SCSel. Does that happen? It would seem not... but > maybe > > it should, which would remove the special-case code that I changed in > that > > commit, and quite likely would simplify much more code besides. > > > > So: Is Coercible_SCSel unfolded during simple_opt? If not, what wonderful > > or terrible things happen if we do? If so, why does > > case-of-known-constructor not work here? My guess is that answering these > > questions may solve the original problem, but this guess could be wrong. > > > > Richard > > > > >

1 0

Re: Hunting down a compilation performance regression involving type families
by David Feuer 06 Jun '17

06 Jun '17

Edward Kmett has explained that this isn't sufficient when things go higher order. His suggested improvement is liftCoercion :: Maybe (Coercion a b -> Coercion (f a) (f b)) David FeuerWell-Typed, LLP -------- Original message --------From: Ryan Scott <ryan.gl.scott(a)gmail.com> Date: 6/6/17 1:41 PM (GMT-05:00) To: Richard Eisenberg <rae(a)cs.brynmawr.edu> Cc: GHC developers <ghc-devs(a)haskell.org>, Eric Mertens <emertens(a)gmail.com> Subject: Re: Hunting down a compilation performance regression involving type families Hrm. It's a shame that supporting this map/coerce RULE causes such pain. This makes me wonder: can we get rid of this RULE? Eric Mertens pointed out a trick [1] that's used in the profunctors library to make mapping coerce over certain Profunctors more efficient. To adapt this trick for Functor, we'd need to add another class method: class Functor f where fmap :: (a -> b) -> f a -> f b (<#>) :: Coercible a b => (a -> b) -> f a -> f b (<#>) = \f -> \p -> p `seq` fmap f p Now, when implementing Functor instances, if we are working with a datatype whose role is representational or phantom, we can make (<#>) really fast: data List a = Nil | Cons a (List a) instance Functor List where fmap = ... (<#>) = coerce Now, instead of relying on (map MkNewtype Nil) to rewrite to Nil, we can just use (MkNewtype <#> Nil)! No map/coerce RULE necessary :) OK, I realize that suggesting that we remove the RULE is perhaps a touch too far. But it does sting that we have to pay hefty compilation penalties because of its existence... Ryan S. ----- [1] http://hackage.haskell.org/package/profunctors-5.2/docs/Data-Profunctor-Uns… . On Wed, May 31, 2017 at 7:25 PM, Richard Eisenberg <rae(a)cs.brynmawr.edu> wrote: > > > On May 31, 2017, at 5:21 PM, Ryan Scott <ryan.gl.scott(a)gmail.com> wrote: > > Does you know what might be going on here? > > I think so, but I don't know how to fix it. > > The commit you found (thank you!) makes simple_opt_expr (the "simple > optimizer", run directly after desugaring, even with -O0) a little more > selective in what `case` expressions it throws away. Previous to that > commit, the optimizer would throw away a `case error "deferred type error" > of _ -> ...` which is terrible. It seems that you have discovered that we > are now too timid in throwing away unhelpful cases. It would be interesting > to know what the newly-retained cases look like, so that we might throw > them away. > > But there remains a mystery: Why do we need this code at all? Reading Note > [Getting the map/coerce RULE to work] closely, it seems we need to simplify > > forall a b (co :: a ~R# b). > let dict = MkCoercible @* @a @b co in > case Coercible_SCSel @* @a @b dict of > _ [Dead] -> map @a @b (\(x :: a) -> case dict of > MkCoercible (co :: a ~R# b) -> x |> co) = let dict = ... in ... > > to > > forall a b (co :: a ~R# b). > map @a @b (\(x :: a) -> x |> co) = \(x :: [a]) -> x |> [co] > > Part of doing so is to drop the `case Coercible_SCSel ...`, which gets in > the way. The mystery is why this needs special code -- shouldn't the > eliminate-case-of-known-constructor do the trick? This would require > unfolding Coercible_SCSel. Does that happen? It would seem not... but maybe > it should, which would remove the special-case code that I changed in that > commit, and quite likely would simplify much more code besides. > > So: Is Coercible_SCSel unfolded during simple_opt? If not, what wonderful > or terrible things happen if we do? If so, why does > case-of-known-constructor not work here? My guess is that answering these > questions may solve the original problem, but this guess could be wrong. > > Richard > >

2 1

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

Interested to help with error messages
by Siddharth Bhat 06 Jun '17

06 Jun '17

Hello all, Thanks for all the work that's put into GHC :) I've tried to get into GHC development before, but I was unsuccessful, mostly because I didn't dedicate enough time to understanding the problem at hand & exploring the codebase. I'd like to give it another shot. This time, I think I have a clear vision of what I want to help with: Have haskell's error messages be easier to read and understand. 1. Colors and layout to highlight important parts of the error messages 2. Clear formatting & naming of errors, so they're easily googleable, stack-overflow able, etc. 3. better hints with error messages, and perhaps integrated lints(?). 4. I don't know if this is already possible, but allowing GHC errors to be shipped off as JSON or something to interested tooling. I saw this ticket on trac: https://ghc.haskell.org/trac/ghc/ticket/8809 I would like to take this up, but I'd like help / pointers and stuff. I have GHC setup, I know how to use phabricator, but.. where do I start? :) Thanks, S~iddharth -- Sending this from my phone, please excuse any typos!

6 7

Trees that Grow / D3609
by Alan & Kim Zimmerman 05 Jun '17

05 Jun '17

This is a heads up that D3609[1], the first step toward implementing Trees that Grow[2] for the hsSyn AST is about to land in master. The key change is that it is replacing the HsSyn type parameter with one that is an index into a set of type families, enabling the extension points (for a future diff). Any current work in progress branches will need a one-time search and replace of all type parameters as follows RdrName -> GhcPs Name -> GhcRs Var -> GhcTc Id -> GhcTcId Any code that makes use of the GHC API and needs to compile with earlier versions too can do something like #if MIN_VERSION_ghc(8,3,0) type ParseI = GhcPs type RenameI = GhcRn type TypecheckI = GhcTc #else type ParseI = RdrName type RenameI = Name type TypecheckI = Var #endif and then replace the RdrName / Name / Var type params with ParseI / RenameI / TypecheckI. A real world example is in ghc-exactprint[3] Regards Alan [1] https://phabricator.haskell.org/D3609 [2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow [3] https://github.com/alanz/ghc-exactprint/commit/6a6e3cdeb40f9623e9a7fc6f1be9…

1 0

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