- ghc-devs - Haskell.org

Re: [commit: ghc] master: WIP on combined Step 1 and 3 for Trees That Grow, HsExpr (e3ec2e7)
by Joachim Breitner 13 Nov '17

13 Nov '17

Hi Alan, the combined effect of commit e3ec2e7ae94524ebd111963faf34b84d942265b4 WIP on combined Step 1 and 3 for Trees That Grow, HsExpr and commit 438dd1cbba13d35f3452b4dcef3f94ce9a216905 WIP on Doing a combined Step 1 and 3 for Trees That Grow causes a 15% regression in the time it takes to build GHC, according to https://perf.haskell.org/ghc/#compare/fe6848f544c2a14086bcef388c46f4070c22d… Is that a known, expected and accepted regression? Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 4

Asserting vars with different Uniques represent the same Object
by Andreas Klebinger 11 Nov '17

11 Nov '17

My core questions are: * Should variables representing the same thing always have the same unique? * If not how can one assert they actually represent the same thing? Working on the pattern matching code I came across this assertion: > ASSERT(tvs1 `equalLength` ex_tvs ) http://git.haskell.org/ghc.git/blob/HEAD:/compiler/deSugar/MatchCon.hs#l125 tvs1 and ex_tvs are both the existentially quantified type variables of a pattern. One gained by taking apart the pattern itself and one by taking apart the ConLike in the pattern. While as far as I can tell they always represent the same Types they don't always compare as equal. Is there any other stable way to compare them? (By name? Something else?). Or is them not being equal a bug to begin with. Follow up question: The whole assert is essentially a unit test as ex_tvs isn't used outside of the assert. Is there a solution to check these invariants in tests instead of the source code?

2 1

merge issues with new field for FamEqn
by John Leo 11 Nov '17

11 Nov '17

Hi everyone, Today I'm trying to merge the latest HEAD into my work on the explicit forall proposal, and I'm running into a problem I'd like help with. The changes that are affecting me seem to come from the latest Trees that Grow checkins. I had added a field to FamEqn, namely feqn_bndrs: data FamEqn pass pats rhs = FamEqn { feqn_tycon :: Located (IdP pass) , feqn_bndrs :: Maybe [LHsTyVarBndr pass] -- ^ Explicit user-provided binders , feqn_pats :: pats , feqn_fixity :: LexicalFixity -- ^ Fixity used in the declaration , feqn_rhs :: rhs } -- ^ -- - 'ApiAnnotation.AnnKeywordId' : 'ApiAnnotation.AnnEqual', -- 'ApiAnnotation.AnnForall','ApiAnnotation.AnnDot' -- For details on above see note [Api annotations] in ApiAnnotation deriving instance (DataId pass, Data pats, Data rhs) => Data (FamEqn pass pats rhs) When I try to compile now, I get the following errors that I cannot understand. I assume I need to do something else, but I'm not sure what it is, so I'd appreciate any guidance. compiler/hsSyn/HsDecls.hs:1441:1: error: • Could not deduce (Data (XValBinds pass pass), Data (XXValBindsLR pass pass)) arising from a use of ‘k’ from the context: (DataId pass, Data pats, Data rhs) bound by the instance declaration at compiler/hsSyn/HsDecls.hs:(1441,1)-(1442,46) • In the first argument of ‘k’, namely ‘((z FamEqn `k` a1) `k` a2)’ In the first argument of ‘k’, namely ‘(((z FamEqn `k` a1) `k` a2) `k` a3)’ In the first argument of ‘k’, namely ‘((((z FamEqn `k` a1) `k` a2) `k` a3) `k` a4)’ When typechecking the code for ‘gfoldl’ in a derived instance for ‘Data (FamEqn pass pats rhs)’: To see the code I am typechecking, use -ddump-deriv | 1441 | deriving instance (DataId pass, Data pats, Data rhs) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... compiler/hsSyn/HsDecls.hs:1441:1: error: • Could not deduce (Data (XValBinds pass pass), Data (XXValBindsLR pass pass)) arising from a use of ‘k’ from the context: (DataId pass, Data pats, Data rhs) bound by the instance declaration at compiler/hsSyn/HsDecls.hs:(1441,1)-(1442,46) • In the first argument of ‘k’, namely ‘(k (k (z FamEqn)))’ In the first argument of ‘k’, namely ‘(k (k (k (z FamEqn))))’ In the first argument of ‘k’, namely ‘(k (k (k (k (z FamEqn)))))’ When typechecking the code for ‘gunfold’ in a derived instance for ‘Data (FamEqn pass pats rhs)’: To see the code I am typechecking, use -ddump-deriv | 1441 | deriving instance (DataId pass, Data pats, Data rhs) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ John

2 1

Cutting the GHC 8.4 branch
by Ben Gamari 09 Nov '17

09 Nov '17

Hello everyone, As described earlier in the fall, with the GHC 8.4 release we will be trying to hold to a more reliable six-month release cycle. Towards this end we will be generally try to cut major release branches three months before the release date. As GHC 8.4 is slated to be released in February 2018, we are quickly approaching that three-month mark. Consequently I'd like to try cutting a branch next week. There are a few things that need to happen in the interim: * Hadrian needs to be merged (this should be done by the end of the day today) * Tamar's patches bumping our Windows toolchain need to be merged (they are in my merge queue) * A bunch of submodule bumps The remainder of the Trees That Grow work may not be entirely merged by the time we branch but Alan and I will arrange that things are merged after the fact. If you have work that you would like to see merged, please do let me know. If things go according to plan, we will produce our first alpha release shortly after the branch. Cheers, - Ben

1 0

GHC 8.2 GC time stats going negative
by Harendra Kumar 09 Nov '17

09 Nov '17

Hi, I am trying to use the mutator_cpu_ns and mutator_elapsed_ns from GHC 8.2 RTSStats structure retrieved using getRTSStats API documented here - https://hackage.haskell.org/package/base-4.10.0.0/docs/GHC-Stats.html . I am seeing that the values of these stats retrieved about 30 ms later are lower than the values retrieved earlier. Sometimes even after 100 ms the values decrease from the previous ones. However, as the time duration between two calls increase this becomes less and less likely. Is this an expected behavior or am I using it incorrectly? If it is expected, why does it happen, what is the underlying mechanism that makes it happen? Thanks, harendra

2 3

T14394 output
by Ben Gamari 08 Nov '17

08 Nov '17

Hi Simon, It seems that your recent commit 30058b0e45e9 may not be quite right. Specifically, the expected output for T14394 is empty, whereas the test is almost certainly going to produce output. The current output is, pattern Foo :: () => (b ~ a) => a :~~: b -- Defined at <interactive>:5:1 pattern Bar :: forall k2 k1 (a :: k1) (b :: k2). () => (k2 ~ k1, (b :: k2) ~~ (a :: k1)) => a :~~: b -- Defined at <interactive>:11:1 pattern Bam :: () => Ord a => a -> a -> (S a, S a) -- Defined at <interactive>:21:1 Does this look right to you? Cheers, - Ben

2 1

Building on limited memory environments (or does -M really work?)
by Saurabh Nanda 08 Nov '17

08 Nov '17

Hi, We're struggling to get our build pipeline working on CircleCI, which has a 4GB RAM limit. Here are some project stats to set the context: - 1,200+ modules - 36,315 LoC of Haskell - On the local machine with -O1 -j the build takes approx 5.2 GB of RAM [1] Trying to build on CircleCI with -O1 -j fails consistently, as expected. However, the behaviour of -M -j -O1 is erratic, at best. Sometimes it magically works, sometimes it fails. A number of times we've seen GHC take 3.5 GB (as reported by `top`), even though the limit was set to 2.5GB. Here are flags that we've tried in various combinations we've tried. None of them is consistent in building / failing: * -O1 * -j * +RTS -M2621440000 -RTS * +RTS -A32m -RTS * +RTS -n2m -RTS What is the **real** behaviour of the -M option? How does it interact with -j and -A? [1] If I'm reading this correctly - https://gist.github.com/saurabhnanda/c8f8654a7f29c1adb753b357b897b5f3#file-… -- Saurabh.

4 5

tcSubsumes
by Richard Eisenberg 07 Nov '17

07 Nov '17

Hi Simon, Could you take a look at TcSimplify.tcSubsumes? This relatively new function pushes the TcLevel when calling tcSubType, but then doesn't set the TcLevel when calling the solver. Inexplicably, this sometimes works -- even passing the testsuite. Somehow, my work caused this to fail. I fixed it by setting the TcLevel before calling the solver. Two questions: 1. Is this a reasonable fix? 2. (optional) How is it possible that this didn't fail drastically often? Note (to author / reviewers of this function): my astonishment isn't that this error crept into the codebase -- I've done similar many many times. My astonishment is how the testsuite didn't find this error forthwith. Thanks, Richard

2 1

valid substitutions for holes
by Richard Eisenberg 07 Nov '17

07 Nov '17

Hi all, GHC HEAD currently suggests valid in-scope single-identifier substitutions for typed holes (underscores in terms). Some unrelated work somehow changed the output, and I'm wondering if this is a change for the better or for the worse. The test case is this: > f :: Int -> Int -> Int > f x y = _ x y With my patch, GHC now suggests `pure` and `return` as replacements for _ (along with the other top contenders of (-), asTypeOf, and const). (You can also increase the number of suggestions, which will then include (+) and (*) among others.) It's true that `pure` and `return` fit the bill, noting that ((->) Int) is an Applicative. But I doubt these suggestions will help the user. I'm not keen to make fixing this "valid suggestions" feature (which I do really like) a dependency of finishing my patch, but I also don't want the change to output to go unnoticed. So, I'm asking: when I merge my patch, should I post a bug asking for perhaps a priority ordering of suggestions? Thanks, Richard

2 1

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2
by Sven Panne 06 Nov '17

06 Nov '17

2017-11-05 15:37 GMT+01:00 <jpaugh(a)gmx.com>: > A better approach might be to develop a "machine-readable" output format > which then is kept stable, and can be enabled with a flag. Git has a > similar solution. > Without doubt, this is definitely the better approach, but this is hardly what can be achieved for 8.2.2. Adding some flag to get the old behavior back when wanted *is* achievable. > It would be a shame to avoid changes which make the user experience better > simply because other projects cannot sync their development cycle, > Don't get me wrong: I'm all for improving user experience, but making ad hoc changes without enough thought or even a chance to get the old behavior back is probably not the right way to proceed. All SW lives in some kind of ecosystem, so it should behave well in that. And for Emacs users, the user experience has been made much worse. > especially if those projects are not universally used or required. > This is highly a matter of personal taste: No project is "universally used", so this is tautological statement. The question is: Is a minor cosmetic change really worth breaking things in one of the major IDEs? Cheers, S.

3 3