- ghc-devs - Haskell.org

Re: GHC release timing and future build infrastructure
by Ara Adkins 03 Aug '17

03 Aug '17

Heya, I very much agree with the thoughts on the variability of the release cadence. The following is somewhat of a stream of consciousness as I read, so please excuse any lack of coherence. When you talk about the bugs being significant blockers to the latest release I feel like that kind of issue isn't necessarily touched by moving to a shorter release cadence. In fact if we're unwilling to let certain fixes wait a release then it exacerbates the risk of slowing down a release. I'm not really sure what to do about this, other than adopting the mentality that fixes might not make the major release and will have to come in a point upgrade if they can't be merged to the release branch in time. Regarding the benefits of an abbreviated release cycle, we see it quite a lot in the rust community. There's a good amount of community involvement with the new releases, and new features are hotly anticipated as they often occur on a timescale where the enthusiasm is still there. I also feel, though this is purely anecdotal, that the more agile release schedule encourages community contributions as the tangible benefits of contributor work can be realised much more quickly. The number of RFCs in discussion at the moment is evidence of that, I feel. It's not all sunny, however, as having so many rapid releases means that it's sometimes difficult to rally the community around certain releases and feature sets. This is perhaps less of an issue due to the maturity of GHC and its ecosystem, but, like you say, it's important to find a good trade-off between release cadence and stability. Personally, I think Rust's cadence is a touch too short. On a related note, there's a 'checkpoints' initiative to build rallying releases that represent significant milestones in development [1]. This is, however, also tied into Rust's stability story, so only parts of it are relevant to GHC. In terms of automated tooling, I think there is significant benefit from it. Again, using rust as an example, there is cargobomb [2], a significant automated testing initiative that both combines packages on Cargo, and runs their test suites. I feel that a combination of the Stackage LTS and Nightly releases would provide a well-curated subset of Hackage that could possibly be used in a similar fashion. This hits on your item (b). Regarding your questions: - In comparison to rust it can feel like there's significant delay in being able to really use GHC's newest features. I feel like this delay can hinder adoption of the features as much of the enthusiasm for them has died down by the time they're properly available. - With the advent of tools such as `stack`, the compiler upgrade process has almost become trivial. While not everyone uses it, it requires no more work than upgrading to a new LTS release and running `stack setup`. Nevertheless, I could imagine four upgrades a year still being okay if it was manual. - The three release policy is an interesting case as the question of changing it really comes down to how we view the GHC stability story. Personally, I think we want to target a time-period of stability, rather than a number of releases. Whether that time period is 1.5 years (assuming a six-month release cadence), or 3 years (rounding the current release cadence) seems like a totally independent discussion to me. - I think I've covered incentives to contribute in my discussion of Rust above. I hope that's useful! Best, _ara [1] https://github.com/rust-lang/rfcs/pull/2052 [2] https://github.com/rust-lang-nursery/cargobomb > On 1 Aug 2017, at 03:19, Ben Gamari <ben(a)well-typed.com> wrote: > > > Hello everyone, > > I just posted a pair of posts on the GHC blog [1,2] laying out some > thoughts on the GHC release cycle timing [1] and how this relates to the > in-progress Jenkins build infrastructure [2]. When you have a some time > feel free to give them a read and comment (either here or on the Reddit > thread [3]). > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule > [2] https://ghc.haskell.org/trac/ghc/blog/jenkins-ci > [3] https://www.reddit.com/r/haskell/comments/6qt0iv/ghc_blog_reflections_on_gh…

5 7

Restructuring hsSyn
by Shayan Najd 03 Aug '17

03 Aug '17

Currently AST declarations, their relate utilities, and `Outputable` instances are defined in the same files. Does anyone object to moving `Outputable` instances to separate files? The purpose is to gradually identify reusable functionalities, group them together, polish them (e.g., remove some unnecessary dependencies), and expose them to the end-users. At this stage, I don't expect any changes outside hsSyn. /Shayan

3 2

Limited availability next week
by Ben Gamari 02 Aug '17

02 Aug '17

Hello everyone, I will be travelling starting tomorrow through next week. During this time I'll still try to check in on things once a day to make sure nothing is burning down. However, I will be a bit less available. Still feel free to ping me via email or IRC, however. I'll try to get back to you. Cheers, - Ben

1 0

GHC release timing and future build infrastructure
by Ben Gamari 02 Aug '17

02 Aug '17

Hello everyone, I just posted a pair of posts on the GHC blog [1,2] laying out some thoughts on the GHC release cycle timing [1] and how this relates to the in-progress Jenkins build infrastructure [2]. When you have a some time feel free to give them a read and comment (either here or on the Reddit thread [3]). Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule [2] https://ghc.haskell.org/trac/ghc/blog/jenkins-ci [3] https://www.reddit.com/r/haskell/comments/6qt0iv/ghc_blog_reflections_on_gh…

3 2

Occurrence info on binders and STG
by Gabor Greif 02 Aug '17

02 Aug '17

Hi devs! I just had a short exchange with Joachim, he sent me to this place. Can anybody explain how occurrence info is used in STG? Cheers and thanks, Gabor ---------- Forwarded message ---------- From: Joachim Breitner <mail(a)joachim-breitner.de> Date: Tue, 01 Aug 2017 10:47:48 -0400 Subject: Re: [commit: ghc] master: Simplify OccurAnal.tagRecBinders (b311096) To: Gabor Greif <ggreif(a)gmail.com> Hi, feel free to CC the mailing list on such questions. I often don’t know things perfectly either. Am Dienstag, den 01.08.2017, 16:43 +0200 schrieb Gabor Greif: > > Loosely related question: Very loosely :-) > - when doing STG Cse, the occurrence info is not updated when a > wild(card)-binder is used. Is there a recommended way to re-run > occ-analysis on STG? (I fear there is not.) I fear that too. It the occ info used past that stage? > - I noticed that "wild"-binders sometimes do not appear at their > binding site (after "of" and "{") in STG dumps. Dumping gets > suppressed when they are deemed dead. Should STG consider occ-info at > all? Good questions. I remember that Simon commented on that before, but I don’t remember where… > oachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 1

RE: [commit: ghc] wip/T14068: Avoid name capture in setJoinResTy (6a50466)
by Simon Peyton Jones 02 Aug '17

02 Aug '17

Joachim Aha! I think my comment on Phab is redundant. You are simply avoiding name capture, which is obviously right; you are not restricting the applicability of the transformation. Needless to say, a Note would help in due course. S | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 02 August 2017 04:07 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] wip/T14068: Avoid name capture in setJoinResTy | (6a50466) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : wip/T14068 | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha | skell.org%2Ftrac%2Fghc%2Fchangeset%2F6a5046684f93f1870663119b447fff6ba | eb7a7c4%2Fghc&data=04%7C01%7Csimonpj%40microsoft.com%7Cc45ce3f4deea476 | 9222b08d4d953af74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363724 | 00832017356%7CUnknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi | IsIkFOIjoiT3RoZXIifQ%3D%3D%7C- | 1&sdata=29Iajm6oTE3Zm%2Bdl5ocMav7MPw%2FniO9%2BVeuQm38qWXQ%3D&reserved= | 0 | | >--------------------------------------------------------------- | | commit 6a5046684f93f1870663119b447fff6baeb7a7c4 | Author: Joachim Breitner <mail(a)joachim-breitner.de> | Date: Tue Aug 1 22:48:26 2017 -0400 | | Avoid name capture in setJoinResTy | | | >--------------------------------------------------------------- | | 6a5046684f93f1870663119b447fff6baeb7a7c4 | compiler/types/Type.hs | 22 ++++++++++++++++------ | 1 file changed, 16 insertions(+), 6 deletions(-) | | diff --git a/compiler/types/Type.hs b/compiler/types/Type.hs index | 50a35b0..c69d4ff 100644 | --- a/compiler/types/Type.hs | +++ b/compiler/types/Type.hs | @@ -2445,11 +2445,21 @@ setJoinResTy :: Int -- Number of binders to | skip | -> Type -- New type | -- INVARIANT: If any of the first n binders are foralls, those tyvars | cannot | -- appear in the original result type. See isValidJoinPointType. | +-- | +-- When we set the return type under a forall, avoid capture! | setJoinResTy orig_ar new_res_ty orig_ty | - = go orig_ar orig_ty | + = go init_subst orig_ar orig_ty | where | - go 0 _ = new_res_ty | - go n ty | Just (arg_bndr, res_ty) <- splitPiTy_maybe ty | - = mkPiTy arg_bndr (go (n-1) res_ty) | - | otherwise | - = pprPanic "setJoinResTy" (ppr orig_ar <+> ppr orig_ty) | + init_subst :: TCvSubst | + init_subst = mkEmptyTCvSubst (mkInScopeSet (tyCoVarsOfType | + new_res_ty)) | + | + go _ 0 _ = new_res_ty | + go subst n ty | + | Just (t, ty') <- splitForAllTy_maybe ty | + , let (subst', t') = substTyVarBndr subst t | + = mkForAllTy t' Inferred (go subst' (n-1) ty') | + | Just (arg_ty, ty') <- splitFunTy_maybe ty | + , let arg_ty' = substTy subst arg_ty | + = mkFunTy arg_ty' (go subst (n-1) ty') | + | otherwise | + = pprPanic "setJoinResTy" (ppr orig_ar <+> ppr orig_ty) | | _______________________________________________ | 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%7Cc45ce3f4deea4769222b0 | 8d4d953af74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363724008320 | 17356%7CUnknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO | IjoiT3RoZXIifQ%3D%3D%7C- | 1&sdata=7%2FAY0EcihvMkjGOHdYdpOog2Roahk0XD%2BunNg54pKFc%3D&reserved=0

1 0

dataToTag# documentation
by David Feuer 02 Aug '17

02 Aug '17

dataToTag# is documented as getting the tag number of an enumeration, which is perfectly reasonable because it's designed to support deriving Enum. But it *appears* to work also for non-enumeration datatypes: dataToTag# Nothing = 0# dataToTag# (Just 3) = 1# Does this actually always work? If so, should that be documented, or is there a realistic possibility that its behavior will change in the future? Additionally: the documentation for dataToTag# urges readers to use GHC.Base.getTag instead. But dataToTag# is exported from the "public" GHC.Exts, whereas getTag is not. Should we add getTag to GHC.Exts, or change the documentation for dataToTag#? David

2 1

code layout of cryptarithm1
by Joachim Breitner 01 Aug '17

01 Aug '17

Hi, if you look at https://perf.haskell.org/ghc/#graph/nofib/time/cryptarithm1 you see that it’s performance varies a lot, sometimes by 10%, between commits should have nothing to do with performance. But most (not all!) of the commits where the performance changes affect the runtime in some way. I conclude that there is something about the code layout that makes this program run faster or slower. If anyone here enjoys tracing and understanding such low-level issues: Here is a nice target to aim at. (I don’t… but I’d appreciate less noise from gipeda :-)) Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

GHC 8.2 generated code faster than 8.0 but slower than 7.10
by Harendra Kumar 01 Aug '17

01 Aug '17

Unicode normalization library ( https://github.com/harendra-kumar/unicode-transforms) shows around 10% improvement with GHC 8.2.1 when compared to GHC 8.0.1, across most benchmarks. However, it is still somewhat slower when compared to GHC 7.10.3. Here are some results: GHC 7.10.3: benchmarking unicode-transforms-text/NFD/English time 4.823 ms (4.765 ms .. 4.902 ms) benchmarking unicode-transforms-text/NFD/Devanagari time 16.46 ms (16.24 ms .. 16.78 ms) GHC 8.0.1 benchmarking unicode-transforms-text/NFD/English time 6.330 ms (6.232 ms .. 6.439 ms) benchmarking unicode-transforms-text/NFD/Devanagari time 18.02 ms (17.77 ms .. 18.22 ms) GHC 8.2.1 benchmarking unicode-transforms-text/NFD/English time 5.659 ms (5.594 ms .. 5.740 ms) benchmarking unicode-transforms-text/NFD/Devanagari time 16.48 ms (16.30 ms .. 16.69 ms) This library has been optimized with an objective to match or better (in some cases it is better) the performance of the equivalent ICU C++ library (compare only decompose normalization). Some of the last hurdles to match the best case of C++ were in the code generated by GHC. Also, for GHC 7.10 LLVM generated code is significantly faster than GHC native, I have not yet tested LLVM backend with 8.2.1 so not sure if that too has improved correspondingly. I just wanted to share these results with the GHC devs. Thanks for all the good work. Also wondering which specific changes might have caused this improvement. Thanks, Harendra

2 2

Operating on HsSyn
by Simon Peyton Jones 31 Jul '17

31 Jul '17

Devs, Shayan is working away on "Trees that grow"... do keep it on your radar: To: ghc-devs Sent: 25 May 2017 23:49 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 Meanwhile I have a question. When pretty-printing HsSyn we often have a situation like this: data Pass = Parsed | Renamed | Typechecked data HsExpr (p :: Pass) = HsVar (IdP p) | .... type famliy IdP p where IdP Parsed = RdrName IdP Renamed = Name IdP Typechecked = Id instance (Outputable (IdP p)) => Outputable (HsExpr p) where ppr (HsVar v) = ppr v The (ppr v) requires (Outputable (IdP p)), hence the context. Moreover, and more seriously, there are things we just can't pretty-print right now. For example, HsExpr has this data constructor: data HsExpr p = ... | OpApp (LHsExpr p) (LHsExpr p) (PostRn p Fixity) (LHsExpr p) To pretty-print the third argument, we'd need to add instance (Outputable (IdP p), Outputable (PostRn p Fixity)) -- New => Outputable (HsExpr p) where ppr (HsVar v) = ppr v and that gets onerous. So today we never print these annotations, to avoid bloating the instance contexts, which can be painful. It bit me yesterday. We have bitten that bullet for the Data class: look at HsExtension.DataId, which abbreviates the long list of dictionaries: type DataId p = ( Data p , ForallX Data p , Data (NameOrRdrName (IdP p)) , Data (IdP p) , Data (PostRn p (IdP p)) , Data (PostRn p (Located Name)) , Data (PostRn p Bool) , Data (PostRn p Fixity) ,..and nine more... ) Let me note in passing that [wiki:QuantifiedContexts<https://ghc.haskell.org/trac/ghc/wiki/QuantifiedContexts>] would make this somewhat shorter type DataId p = ( Data p , ForallX Data p , Data (NameOrRdrName (IdP p)) , Data (IdP p) , forall t. Data t => Data (PostRn p t)) But we still need one item in this list for each type function, and I am worried about how this scales to the [wiki:ImplementingTreesThatGrow<https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow>] story, when we have a type function for each data constructor -- and there are a lot of data constructors. So I have four questions 1. I think we should probably use a superclass instead of a type synonym class (Data p, ForallX Data p, ....) => DataId p where {} Why? Only one argument to pass, and to pass on to successive calls. I see no downside. 1. Shall we treat Outputable like Data? (I.e. make an abbreviation for a long list of Outputable instances and use it everywhere) 2. I thought of another way to do it (pass a token); see below 1. Are there any other ways? Token passing idea. Perhaps instead of passing lots of functions, we pass a singleton token that encodes the pass, like this: instance (PassC p) => Outputable (HsExpr p) where ppr (HsVar v) = case getPass :: IsPass p of IsParsed -> ppr v IsRenamed -> ppr v IsTypechecked -> ppr v The three ppr's are at different types, of course; that's the point. The infrastructure is something like class PassC p where getPass :: IsPass p data IsPass p where IsParsed :: IsPass Parsed IsRenamed :: IsParsed Renamed IsTypechecked :: IsParsed Typechecked instance PassC Parsed where getPass = IsParsed ...etc... Now we could sweep away all those OutputableX classes, replacing them with dynamic tests on the singletons IsParsed etc. This would have advantages: - Probably faster: there's a dynamic test, but many fewer dictionary arguments and higher-order function dispatch - Only one dictionary to pass; programming is easier. The big downside is that it's not extensible: it works only because we know the three cases. But the "Trees that Grow" story really doesn't scale well to pretty-printing: so maybe we should just give up on that?

4 10