- ghc-devs - Haskell.org

whats the current state of runtime rep for ghc 8 onwards?
by Carter Schonwald 05 Apr '16

05 Apr '16

i was reading https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds and looking at some of the applicable code, and it looks like i can't quantify over ptr-y heap values that may or may not be lifted, at least with the current state of play, is this correct?

2 3

Initial compile time benchmarks
by Ömer Sinan Ağacan 01 Apr '16

01 Apr '16

Hi all, Using Ben's timing patch [^1], Cabal, and a Haskell program to parse generated logs [^2], I generated some tables that show compile times of modules in hxt, haskell-src-exts, lens, and all of their dependencies: https://gist.githubusercontent.com/osa1/fd82335181a584679c9f3200b7b0a8a5/ra… Some notes: - Modules and passes in modules are sorted. - At the end of the file you can see the cumulative numbers for the passes. In fact, that's a small table so I'm just going to paste it here: ======================Total====================== CodeGen 41.32% Simplifier 34.83% Renamer/typechecker 12.22% Desugar 2.11% CorePrep 1.90% Demand analysis 1.44% CoreTidy 1.35% Called arity analysis 1.10% Float inwards 0.96% Common sub-expression 0.87% Parser 0.75% SpecConstr 0.57% Specialise 0.30% Worker Wrapper binds 0.17% Liberate case 0.12% ByteCodeGen 0.00% Simplify 0.00% I don't know how to make use of this yet, but I thought ghc-devs may find it useful. As a next thing I'm hoping to add some more `withTiming` calls. The analyze program can handle nested `withTiming` calls and renders passes as a tree (GHC HEAD doesn't have nested `withTiming`s so we don't see it in the file above), so we can benchmark things in more details. I also want to experiment a little bit with different `force` parameters to `withTiming`. If anyone has any other ideas I can also try those. --- [^1]: https://phabricator.haskell.org/D1959 [^2]: https://github.com/osa1/analyze-ghc-timings

7 10

Perf
by Simon Peyton Jones 31 Mar '16

31 Mar '16

Joachim Harbormaster seems to be saying that GHC’s perf got a lot worse https://phabricator.haskell.org/harbormaster/ after Buildable 9015, which omitted the oneshot info. The typechecker seems to allocate a lot more. That is not good. Revert and investigate? Simon

2 2

RE: [commit: ghc] master: Refactor in TcMatches (bdd9042)
by Simon Peyton Jones 31 Mar '16

31 Mar '16

Ben, Austin The group of around six refactoring patches I have just committed are inessential for 8.0, but I think they are solid enough to merge if some other later patch depends on them. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 31 March 2016 08:02 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Refactor in TcMatches (bdd9042) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.has | kell.org%2ftrac%2fghc%2fchangeset%2fbdd90426a7f88d57bedf15411fa00f62aeb | 22172%2fghc&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c23c66899d | 70e4e74cd8608d35932b916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Lw | 9ByEHKPpKZb%2fsgZQc1dpCjTm8yNAh5%2b1izy9PdgX0%3d | | >--------------------------------------------------------------- | | commit bdd90426a7f88d57bedf15411fa00f62aeb22172 | Author: Simon Peyton Jones <simonpj(a)microsoft.com> | Date: Wed Mar 30 17:14:11 2016 +0100 | | Refactor in TcMatches | | * Move the several calls of tauifyMultipleMatches into tcMatches, | so that it can be called only once, and the invariants are | clearer | | * I discovered in doing this that HsLamCase had a redundant and | tiresome argument, so I removed it. That in turn allowed some | modest but nice code simplification | | | >--------------------------------------------------------------- | | bdd90426a7f88d57bedf15411fa00f62aeb22172 | compiler/deSugar/Coverage.hs | 2 +- | compiler/deSugar/DsExpr.hs | 7 +++---- | compiler/deSugar/DsMeta.hs | 2 +- | compiler/hsSyn/Convert.hs | 3 +-- | compiler/hsSyn/HsExpr.hs | 16 +++++++++------- | compiler/parser/Parser.y | 2 +- | compiler/rename/RnExpr.hs | 5 ++--- | compiler/typecheck/TcExpr.hs | 17 +++++++++-------- | compiler/typecheck/TcHsSyn.hs | 7 +++---- | compiler/typecheck/TcMatches.hs | 24 ++++++++---------------- | compiler/typecheck/TcRnTypes.hs | 2 +- | 11 files changed, 39 insertions(+), 48 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 | bdd90426a7f88d57bedf15411fa00f62aeb22172 | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha | skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c23c66899d70e4 | e74cd8608d35932b916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8kgpTH | G1JUjyHegki%2bBXMZ6gdSlUReHDY5pQIdaUqMg%3d

1 0

nix build haskell.compiler.ghcHEAD
by Rahul Muttineni 31 Mar '16

31 Mar '16

Hi GHC Devs, Refer https://github.com/NixOS/nixpkgs/issues/14333 for a problem I was having when building with nix. The interesting part is that if I add an extra flag -optl-lpthread manually, the error goes away and the build succeeds. My question is why the build system didn't add the -optl-lpthread flag when libpthread was a requirement for that particular build? Thanks, Rahul Muttineni

1 1

Unicode, strings, and Show
by Manuel M T Chakravarty 31 Mar '16

31 Mar '16

Why are we doing this? GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> "文字" "\25991\23383" Prelude> After all, we don’t print ’a’ as ’\97’. Manuel

7 12

GHC HEAD compile failure at ghctags: "missing: Cabal >=1.25 && <1.27"
by Conal Elliott 30 Mar '16

30 Mar '16

I'm trying to recompile GHC (via GHC 7.10.3) from freshly git-pulled HEAD, and "make" keeps dying at ghctags: Configuring ghctags-0.1... ghc-cabal: At least the following dependencies are missing: Cabal >=1.25 && <1.27 According to ghc-pkg I have Cabal 1.25.0.0 (compiled from a freshly git-pulled git clone). Any ideas what's going on and how I can fix it? Thanks. - Conal

2 2

singletons stuff in GHC.Generics?
by Carter Schonwald 30 Mar '16

30 Mar '16

Hey All, i just noticed that theres some Singletons code in the GHC.Generics module thats defined but not exported, whats the context on that? https://ghc.haskell.org/trac/ghc/ticket/11775#ticket is the ticket i created to track / ask for clarificaiton:) _Carter

2 2

Re: instantiating visible parameters in when deriving instances
by Ryan Scott 29 Mar '16

29 Mar '16

Simon, did you meant P2? (Since you can't write instance (k ~ *) => Functor (P1 (a :: k)), as that's ill-kinded). Something like this? data P2 k (a :: k) = MkP2 instance (k ~ *) => Functor (P2 k) That's an interesting idea. Be aware that you actually can't compile that code at the moment, since GHC complains: * Expected kind ‘* -> *’, but ‘P2 k’ has kind ‘k -> *’ * In the first argument of ‘Functor’, namely ‘P2 k’ In the instance declaration for ‘Functor (P2 k)’ I hope this is a bug and not a fundamental limitation. There's another wrinkle in the design we must consider. Not only can datatypes have dependent type parameters, but so can typeclasses themselves. Consider: {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeInType #-} module Cat where import Data.Kind class Cat k (cat :: k -> k -> *) where catId :: cat a a catComp :: cat b c -> cat a b -> cat a c instance Cat * (->) where catId = id catComp = (.) newtype Fun a b = Fun (a -> b) deriving (Cat k) I was surprised to find out that this code currently compiles without issue on GHC 8.0, even though we're deriving (Cat k) instead of (Cat *). This is an effect of the way GHC currently handles deriving clauses, since it unifies the kind of the datatype and typeclass beforehand (therefore, it silently gets unified to Cat * before generating the instance). [1] Is this correct? It definitely feels a bit off. We currently allow this (see Trac #8865 [2]): newtype T a b = MkT (Either a b) deriving ( Category ) Even though Category :: k -> k -> * (i.e., we silently unify k with *). The difference here, as is the difference between P1 and P2 in Simon's email, is that k is not visible, so it's out-of-sight and out-of-mind. When k is visible, as in Cat, when now must be conscious of how it's used in a deriving clause. The Cat code is lying in the sense that we aren't deriving an instance that begins with (Cat k), but rather: instance Cat * Fun where ... Using Simon's advice, we could just as well generate: instance (k ~ *) => Cat k Fun where ... (Again, this doesn't currently compile on 8.0. I really hope that's just a bug.) So I'm starting to lean towards Simon's proposal. That is, we freely unify non-visible type parameters when deriving, but if a type parameter is visible, then we generate equality constraints instead of unifying it. Ryan S. ----- [1] http://git.haskell.org/ghc.git/blob/b0ab8db61568305f50947058fc5573e2382c84e… [2] https://ghc.haskell.org/trac/ghc/ticket/8865

3 3

GHC 8.0.1 release plan
by Ben Gamari 29 Mar '16

29 Mar '16

Hello GHCers, After numerous delays, I think we may finally be converging on a (hopefully final) 8.0.1 release candidate. Thanks to the tireless efforts of Richard Eisenberg, Simon PJ, and many others almost all of the release blocking tickets [1] have now been resolved. There are a few patches currently waiting for review that should hopefully be mergeable within the next few days. After these last patches have been merged I'll proceed in cutting the source distribution for GHC 8.0.1 release candidate 3. This release candidate will be made available immediately, although, in accordance with our new release policy [2], binary distributions won't be available until seven days later. Release candidate 3 will hopefully be the final release candidate for 8.0.1; the final 8.0.1 release will, with luck, be released in mid-April. This has indeed been a rather peculiar release and we hope that we'll be able to stick to a more consistent schedule for future releases. After the 8.0.1 release we'll need to discuss how we'd like to set the timeline for 8.2, our next major release. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1#Ticketsslatedfor8.0.1

2 2