- ghc-devs - Haskell.org

Trees that Grow and constraints
by Alan & Kim Zimmerman 13 Nov '17

13 Nov '17

At the moment the Trees that Grow implementation in GHC master makes use of massive constraint types to provide Data instances for the hsSyn AST. I am trying to remove the need for this, and have hit a problem. The example I have reduced it to is here [1] The essence of the problem is ------------------- data Experiment p = Experiment { e_ext :: (XEOverLit p), e_val :: Int } | XExperiment (XXOverLit p) deriving instance (Data (GhcPass p)) => Data (Experiment (GhcPass p)) type family XEOverLit x type family XXOverLit x -- The following line works -- type instance XEOverLit (GhcPass _) = PlaceHolder -- The following 3 lines do noe type instance XEOverLit (GhcPass 'Parsed ) = PlaceHolder type instance XEOverLit (GhcPass 'Renamed ) = PlaceHolder type instance XEOverLit (GhcPass 'Typechecked) = PlaceHolder type instance XXOverLit (GhcPass _) = PlaceHolder ------------------- Where specifying the type instance with a wild card keeps GHC happy (the XXOverLit case), but specifying for each of the three constructors for pass does not (the XEOverLit case) The exact error message is ------------------------------ Experiment.hs:34:1: error: • Could not deduce (Data (XEOverLit (GhcPass p))) arising from a use of ‘k’ from the context: Data (GhcPass p) bound by the instance declaration at Experiment.hs:34:1-69 • In the first argument of ‘k’, namely ‘(z Experiment `k` a1)’ In the expression: ((z Experiment `k` a1) `k` a2) In an equation for ‘gfoldl’: gfoldl k z Experiment a1 a2 = ((z Experiment `k` a1) `k` a2) When typechecking the code for ‘gfoldl’ in a derived instance for ‘Data (Experiment (GhcPass p))’: To see the code I am typechecking, use -ddump-deriv | 34 | deriving instance (Data (GhcPass p)) => Data (Experiment (GhcPass p)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ------------------------------ Alan [1] http://lpaste.net/360017

3 5

Dynamically choosing the main function
by Harendra Kumar 13 Nov '17

13 Nov '17

Hi, GHC allows choosing a main function at link time using the "-main-is" option. I was wondering if there is a possibility to choose the main function at runtime. Or even better, if something equivalent to "ghc -e" is somehow possible in a linked binary executable. If not, are there any plans to achieve something like that in future? Are there any theoretical, practical obstacles to that? Thanks, Harendra

5 10

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