- ghc-devs - Haskell.org

Build failures with -DDEBUG
by Thomas Miedema 18 Feb '16

18 Feb '16

Simon, the commits you pushed today don't validate with -DDEBUG. Unexpected failures: patsyn/should_compile MoreEx [exit code non-0] (normal) patsyn/should_compile T11224b [exit code non-0] (normal) polykinds MonoidsTF [exit code non-0] (normal) polykinds T11480b [exit code non-0] (normal) polykinds T11523 [exit code non-0] (normal) typecheck/should_fail TcCoercibleFail [stderr mismatch] (normal) TcCoercibleFail timed out, and the others all hit the following debug assert: =====> T11224b(normal) 2510 of 5029 [0, 0, 0] Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160218 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:1932:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:1991:17 in ghc:TyCoRep substTys, called at compiler/types/TyCoRep.hs:2012:14 in ghc:TyCoRep substTheta, called at compiler/typecheck/TcPatSyn.hs:255:20 in ghc:TcPatSyn in_scope InScope {d_ap0 c_apv} tenv [ap1 :-> c_apv[tau:5]] tenvFVs [aps :-> t_aps[tau:1], apv :-> c_apv[tau:5]] cenv [] cenvFVs [] tys [] cos [] Complete log from Travis: https://s3.amazonaws.com/archive.travis-ci.org/jobs/110115377/log.txt -- Thomas

2 1

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?
by Andrey Mokhov 18 Feb '16

18 Feb '16

Thomas Tuegel <ttuegel(a)gmail.com> writes: > > What exactly does the pre-process phase do, anyways? > It runs the appropriate pre-processor (Alex, Happy, c2hs, etc.) for modules > that require it. It's slow because of the way the process is carried out: For > each module in the package description, Cabal tries to find an associated .hs > source file in the hs-source-dirs. If it cannot, it looks for a file with an > extension matching one of the pre-processors it knows about. If it finds one, > it runs the corresponding program if the output files are missing or outdated. Interesting! In the new Shake-based build system we also need to automagically generate .hs files using Alex et al. My first implementation was slow but then I realised that it is possible to scan the source tree only once and remember where all .hs/.x/etc files are. This brought down the complexity from quadratic to linear in my case -- maybe this could be reused in cabal too? By the way, there seem to be a fair amount of code & functionality overlap in cabal and the new build system. We might want to look into this once the build system becomes more stable. Cheers, Andrey

3 3

Strict Haskell
by Simon Peyton Jones 18 Feb '16

18 Feb '16

Johan Consider this with -XStrict f y = let Just x = blah[y] in body[y,x] Suppose that in a call to f, · blah returns Nothing · but body does not use x Should f succeed? For sure, blah will be evaluated to HNF before body is started, but is the match against Just done strictly too? According to our current semantics, in the match against Just is not done strictly, so the call should succeed. I think that’s unexpected and probably wrong. Here’s the semantics http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#recu… The translation for !(Just x) = blah ð (FORCE) v = blah; Just x = v (and add a seq on v) ð (SPLIT) v = blah; x = case v of Just x -> x So we finish up with f y = let v = blah[y] in let x = case v of Just x -> x in v `seq` body[y,x] I don’t think that’s what you intended. If the pattern can fail, I think we want the FORCE step to say this: Replace any binding !p = e with v = case e of p -> (v1,..,vn); (v1,..,vn) = v and replace e0 with v seq e0, where v is fresh and v1..vn are the variable(s) bound by p (Compare with the text at the above link.) Do you agree? Simon

1 0

Fwd: Is anything being done to remedy the soul crushing compile times of GHC?
by Manuel M T Chakravarty 18 Feb '16

18 Feb '16

There is currently an interesting discussion on Reddit on GHC compile times https://www.reddit.com/r/haskell/comments/45q90s/is_anything_being_done_to_… I feel that this is a serious problem; so, it probably ought to be discussed here as well. Manuel

11 19

Installing Cabal for GHC 8.0 release candidates
by Ben Gamari 17 Feb '16

17 Feb '16

Hello everyone, Our wonderful Cabal release manager Mikhail Glushenkov has kindly uploaded candidate releases of Cabal and cabal-install for use by GHC 8.0 release candidate users. Now updating to a GHC 8.0-compatible Cabal/cabal-install should be as simple as, cabal install \ http://hackage.haskell.org/package/Cabal-1.23.1.0/candidate/Cabal-1.23.1.0.… \ http://hackage.haskell.org/package/cabal-install-1.23.0.0/candidate/cabal-i… Happy testing! Cheers, - Ben

2 2

Impredicative types and forall regression in 8.0 ?
by Vincent Hanquez 16 Feb '16

16 Feb '16

Hi GHC-Devs, I recently came across a compilation problem on 8.0 that do not trigger on < 8.0. I've reduced the issue to this snippet with Rank2Types: type Action = (forall a . Show a => a) -> Int data Command = Command (Maybe Action) com1 = Command Nothing With GHC 7.0 to 7.10, this compile and works. However on GHC 8.0, I now have: Test.hs:19:16: error: • Cannot instantiate unification variable ‘a0’ with a type involving foralls: Action GHC doesn't yet support impredicative polymorphism • In the first argument of ‘Command’, namely ‘Nothing’ In the expression: Command Nothing In an equation for ‘com1’: com1 = Command Nothing I workarounded it by "inlining" the maybe and creating a proper wrapping type: data Action2 = Action2 ((forall a . Show a => a) -> Int) | NoAction2 data Command2 = Command2 Action2 com2 = Command2 NoAction2 Any idea why this is triggering this issue in GHC 8.0 ? Is this something that need fixing maybe ? Cheers, -- Vincent

3 3

quick performance measurements
by Richard Eisenberg 15 Feb '16

15 Feb '16

Hi devs, I have a few ideas for tweaks to improve compiler performance. (For example, reversing the order of comparisons in a short-circuiting comparison operation.) I don't have a particular test case with a profile that tells me where the smoking gun is. But I'd like to try these easy tweaks just to see if performance improves. My question: Is there an easy way to run some command that will give me helpful feedback on my performance tweak? Of course, I could push to a branch and have perf.haskell.org tell me. But that takes a long time. I could compile a few files and examine the output manually. But that's a bit painful. Ideally, there would be a way to run a portion of the testsuite and have the testsuite tool aggregate performance characteristics and report. Or perhaps there's a way to get cabal to aggregate performance characteristics, and I could just try compiling a few libraries. Any ideas out there? Thanks! Richard

5 6

New type of expressions containing (error ...) includes noisy implicit parameter
by Christopher Allen 15 Feb '16

15 Feb '16

Prelude> let myList = [1, 2, 3 :: Integer] Prelude> let myList' = myList ++ undefined Prelude> :t myList myList :: [Integer] Prelude> :t myList' myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer] This is on by default and insofar as I've been able to try, it's avoidable in a default GHCi 8.0 REPL session. I'm glad I caught this before our book goes to print in a couple months. We'd managed to avoid talking about implicit parameters in 1,100+ pages of book but now we're forced to acknowledge their existence in the 4th of 32 chapters. This slipped past the radar more stealthily than the earlier stages of BBP did for 7.10. I was hearing about BBP on the GHC Trac pretty early on for months on end. Was the thinking that people still used implicit parameters for anything or taught them? On the one hand, this is a nice change and something I personally attempted (and failed) to make easier in GHC 7.10. The implementation making the types noisy rankles and didn't seem necessary when I investigated it between 7.8 and 7.10. Could you warn us when (educationally relevant?) stuff like this is coming down the pipe before the RC please? Ideally during the design phase. I think this was discussed as part of FTP to avoid future debacles. This isn't just a pedagogical problem, this is a UX problem. The users don't _care_ that call stack information is being carried around. Why would they? It happens without any mention in the types in almost every other programming language. --- Chris Allen

5 5

[Template Haskell] Desugaring TH brackets vs. Desugaring normal HsExprS.
by Dominik Bollmann 15 Feb '16

15 Feb '16

Hi, I'm currently trying to understand GHC's implementation of Template Haskell and I've had the following two questions when reading upon deSugar/DsMeta.hs and deSugar/dsExpr.hs (disclaimer: I'm a complete newbie to GHC and do not know pretty much anything about its internals; so please excuse silly questions). 1) As far as I understand DsMeta, its purpose is to desugar the contents of TH quotation brackets, e.g. [| \x -> x |]. Given the HsExpr contents, say `expr`, of a quotation bracket, it creates a CoreExpr /representation/ of `expr` such that /evaluating/ this CoreExpr representation yields a TH expression equivalent to `expr`. (This is similar to how quotations are implemented in the original TH paper). On the other hand, when instead writing the above TH quote, (i.e., [| \x -> x |]), explicitly as newName "x" >>= (\x -> lamE (varP x) (varE x)) (*) there is no need to build a CoreExpr /representation/ because we already got the TH value we're interested in; Hence, in this case DsExpr desugars the above (*) directly to a CoreExpr that represents it. Is my understanding of the above correct? I tried to confirm it using the following to splices: test1 :: Q Exp test1 = [| \x -> x |] test2 :: Q Exp test2 = do x <- newName "x" lamE [(varP x)] (varE x) However, dumping the desugared output of these splices using `-ddump-ds` gives the exact same CoreExprS: test1 :: Q Exp [LclIdX, Str=DmdType] test1 = Language.Haskell.TH.Syntax.bindQ @ Name @ Exp (newName (GHC.CString.unpackCString# "x"#)) (\ (x_a399 :: Name) -> lamE (GHC.Types.: @ PatQ (varP x_a399) (GHC.Types.[] @ PatQ)) (varE x_a399)) test2 :: Q Exp [LclIdX, Str=DmdType] test2 = >>= @ Q Language.Haskell.TH.Syntax.$fMonadQ @ Name @ Exp (newName (GHC.CString.unpackCString# "x"#)) (\ (x_a39a :: Name) -> lamE (GHC.Types.: @ PatQ (varP x_a39a) (GHC.Types.[] @ PatQ)) (varE x_a39a)) Could anyone explain to me why both CoreExpr dumps are the same? Shouldn't the first be a /representation/ that, only when run, yields the second CoreExpr? If anyone could help me understanding this, it'd be great! Thanks, Dominik.

2 1

Reconsidering -Wall and -Wcompat
by Ben Gamari 15 Feb '16

15 Feb '16

tl;dr. GHC has a new set of warnings, -Wcompat, intended to give users advance notice of coming library changes. We want to know whether you think this set should be included in -Wall. See the Wiki [4] and voice your opinion via the linked poll. Hello everyone, GHC 8.0.1 will include a new warning group, -Wcompat, which arose out of the MonadFail proposal discussion [1] late last year. This warning set is intended to provide a means of informing users of coming changes in GHC's core libraries. We would like to solicit the community's feedback on whether this new flag set should be implied by -Wall. This proposal is motivated by concern expressed by some that -Wcompat would see little usage unless it is placed in one of the warning sets typically used during development. One such set is -Wall, which enables a generous fraction of GHC's warning collectionand is is intended [2] for use during development. Unfortunately, despite the (albeit only recently stated) intent of flag, -Wall is widely used outside of development [3], often with the expectation that the result be warning-clean across multiple GHC versions. While we hope that -Wall will see less use in this context in the future, given its current role we wouldn't want to add options to it that would cause undue burden for users. So, we are asking for your opinion: should -Wcompat be implied by -Wall? You can find a more thorough description of the precise proposal on the GHC Wiki [4]. It would be very much appreciated if you could take a few minutes familiarize yourself with the options and provide your thoughts via this quick poll, https://docs.google.com/forms/d/1BmIQvhHcnDB79LgBvaWl_xXpS1q0dMHe3Gq9JeU9od… Feel free to discuss the issue further in this thread. Thank you for sharing, - Ben [1] https://mail.haskell.org/pipermail/ghc-devs/2015-October/010101.html [2] https://mail.haskell.org/pipermail/ghc-devs/2016-January/010955.html [3] In a rather unscientific study, nearly half of packages on Hackage include it in ghc-options, $ tar -xf ~/.cabal/packages/00-INDEX.tar $ (for pkg in $(ls); do ls $pkg/*/*.cabal | sort -r | head -n1; done) | xargs grep -L '\-Wall' | wc -l 4352 $ ls | wc -l 9347 [4] https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings/Wcompat

6 9