- ghc-devs - Haskell.org

The definition of cseProgram
by David Feuer 18 Aug '14

18 Aug '14

Currently, it's defined like this: cseProgram :: CoreProgram -> CoreProgram cseProgram binds = cseBinds emptyCSEnv binds cseBinds :: CSEnv -> [CoreBind] -> [CoreBind] cseBinds _ [] = [] cseBinds env (b:bs) = (b':bs') where (env1, b') = cseBind env b bs' = cseBinds env1 bs Couldn't we replace all that with the following? (Thanks to Cale for suggesting mapAccumL—I was using scanl because I knew it, but it was not a great fit.) cseProgram = snd . mapAccumL cseBind emptyCSEnv David Feuer

2 1

is this a bug: when <<loop>> happens stack trace is reported twice
by Ömer Sinan Ağacan 18 Aug '14

18 Aug '14

Hi all, I just realized that when `+RTS -xc` is used and a <<loop>> error is happened, stack trace is reported twice. This is not the case with `error` calls, in that case stack traces are reported only once. Here's a demonstration: ➜ haskell cat loop.hs myFun :: Int myFun = let g = g + 1 in g + 10 myFun2 :: Int myFun2 = error "unexpected happened" main = print myFun ➜ haskell ./loop +RTS -xc *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.myFun.g, called from Main.myFun, called from Main.CAF *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.myFun.g, called from Main.myFun, called from Main.CAF loop: <<loop>> Here the stack trace is reported twice. If I use `myFun2` instead of `myFun`: ➜ haskell ./loop +RTS -xc *** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace: Main.myFun2, called from Main.CAF --> evaluated by: Main.main, called from Main.CAF loop: unexpected happened Why is this happening in the case of <<loop>> error? Is this expected or is this a bug? I'm willing to trace the code through the RTS and fix it but I just want to make sure that this really is a bug. Thanks. --- Ömer Sinan Ağacan http://osa1.net

1 0

RE: [Haskell-cafe] Wish list for GHC API tooling support
by Simon Peyton Jones 18 Aug '14

18 Aug '14

Based on my experiences with HaRe, I have started putting together a wish list of features I would like to see in it, which is here https://github.com/fpco/haskell-ide/wiki/GHC-API Just to say: I really support having this discussion. The GHC API is not driven enough by the needs of its clients. I think that a client can actually access pretty much any function inside GHC, so no wonder the API feels unstable! Steps forward might be: · Be very clear which functions are part of the official API. I think it’s the ones exported by GHC.lhs · Review them to check they all make sense · Add good Haddock documentation for each of them · Make sure that each is marked, at its definition site, as part of the GHC API. At the moment it is far from clear when one is modifying a function that is part of the GHC API, since most of these functions aren’t in GHC.lhs I’m happy to help, but not as a driving force. Thanks! Simon From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 18 August 2014 09:06 To: haskell Subject: [Haskell-cafe] Wish list for GHC API tooling support At the moment the GHC API is a sort of poor relation in the haskell world, where it could be a significantly useful resource for the growing list of haskell tool providers. Based on my experiences with HaRe, I have started putting together a wish list of features I would like to see in it, which is here https://github.com/fpco/haskell-ide/wiki/GHC-API I welcome feedback / discussion on this. Regards Alan

1 0

Re: [GHC] #9434: GHC.List.reverse does not fuse
by David Feuer 17 Aug '14

17 Aug '14

I'm having trouble when it doesn't fuse—it ends up with duplicate bindings at the top level, because build gets inlined n times, and the result lifted out. Nothing's *wrong* with the code, except that there are multiple copies of it. On Aug 15, 2014 10:58 AM, "GHC" <ghc-devs(a)haskell.org> wrote: > #9434: GHC.List.reverse does not fuse > -------------------------------------+------------------------------------- > Reporter: dfeuer | Owner: > Type: bug | Status: new > Priority: normal | Milestone: > Component: | Version: 7.9 > libraries/base | Keywords: > Resolution: | Architecture: Unknown/Multiple > Operating System: | Difficulty: Easy (less than 1 > Unknown/Multiple | hour) > Type of failure: Runtime | Blocked By: > performance bug | Related Tickets: > Test Case: | > Blocking: | > Differential Revisions: | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > Great. Just check that when fusion ''doesn't'' take place, the result is > good. And do a `nofib` comparison for good luck. Then submit a patch. > > Thanks for doing all this work on fusion, David. > > Simon > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9434#comment:2> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

3 5

Wired-in data-constructors with UNPACKed fields
by Herbert Valerio Riedel 17 Aug '14

17 Aug '14

Hello *, I'm a bit stuck with the wired-in type aspect of integer-gmp2 and was hoping someone with more experience in this area could provide direction on how to properly register the data definition data Integer = SI# Int# | Jp# {-# UNPACK #-} !BigNat | Jn# {-# UNPACK #-} !BigNat data BigNat = BN# ByteArray# with compiler/prelude/TysWiredIn.lhs Right now I'm getting the Lint-failure Unfolding of sqrInteger <no location info>: Warning: In the expression: $wsqrBigNat dt Argument value doesn't match argument type: Fun type: ByteArray# -> BigNat Arg type: BigNat Arg: dt where sqrBigNat :: BigNat -> BigNat which seems to be caused by the UNPACK property not being handled correctly. The full error message can be found at http://git.haskell.org/ghc.git/commitdiff/13cb42bc8b6b26d3893d4ddcc22eeab36… and the other half of the integer-gmp2 patch can be found at http://git.haskell.org/ghc.git/commitdiff/b5ed2f277e551dcaade5837568e4cbb7d… or alternatively https://phabricator.haskell.org/D82 Thanks in advance, hvr

2 1

Broken Data.Data instances
by p.k.f.holzenspies＠utwente.nl 15 Aug '14

15 Aug '14

Dear GHC-ers, Is there a reason for explicitly broken Data.Data instances? Case in point: > instance Data Var where > -- don't traverse? > toConstr _ = abstractConstr "Var" > gunfold _ _ = error "gunfold" > dataTypeOf _ = mkNoRepType "Var" I understand (vaguely) arguments about abstract data types, but this also excludes convenient queries that can, e.g. extract all types from a CoreExpr. I had hoped to do stuff like this: > collect :: (Typeable b, Data a, MonadPlus m) => a -> m b > collect = everything mplus $ mkQ mzero return > > allTypes :: CoreExpr -> [Type] > allTypes = collect Especially when still exploring (parts of) the GHC API, being able to extract things in this fashion is very helpful. SYB's "everything" being broken by these instances, not so much. Would a patch "fixing" these instances be acceptable? Regards, Philip

6 29

Help with fusion rules and such
by David Feuer 14 Aug '14

14 Aug '14

I've worked out the basics of how to make more functions from GHC.Base, GHC.List, and Data.List participate in foldr/build fusion, but I could really use some help figuring out how to write the RULES to accompany them. I have too little experience with GHC's simplification process to manage this on my own, it seems. One complication I recognize already: REVERSE reverse xs = build $ \c n -> foldl (\a x -> x `c` a) n xs works as well as we can probably expect for fusion (it fuses nicely with map and a modified unfoldr), but when it doesn't fuse, it ends up duplicating its "worker" at the top level, potentially multiple times. I tried to write a rule to rewrite that to a simpler version, but that's complicated by the fact that foldl is INLINEd unconditionally. I'm thinking maybe the "right" thing is to allow all this duplication to happen, and then clean it up at the end ( see https://ghc.haskell.org/trac/ghc/ticket/9441 ), but that will not happen soon if it does at all.

1 0

ARM64 Task Force
by Luke Iannini 14 Aug '14

14 Aug '14

Howdy all, Would anyone like to team up on getting ARM64 support into GHC? Cheers Luke

4 11

making ./validate run tests on all CPUs by default
by Sergei Trofimovich 13 Aug '14

13 Aug '14

Good evening all! Currently when being ran './validate' script (without any parameters): - builds ghc using 2 parallel jobs - runs testsuite using 2 parallel jobs I propose to change the default value to amount of available CPUs: - build ghc using N+1 parallel jobs - run testsuite using N+1 parallel jobs Pros: - first-time users will get faster ./validate - seasoned users will need less tweaking for buildbots Cons: - for imbalanced boxes (32 cores, 8GB RAM) it might be quite painful to drag box out of swap What do you think about it? Actual patch: https://phabricator.haskell.org/D146 Thanks! -- Sergei

2 2

Grumpy harbormaster
by Ben Gamari 13 Aug '14

13 Aug '14

I submitted two unrelated differentials today, D152 and D150. Somehow the Harbormaster builds of both have failed in the same peculiar way, silently dying apparently after right after finishing the initial ghc-cabal build. It's entirely possible I'm missing something silly here, but neither of the patches touch anything near Cabal or the build system so I'm a bit perplexed. What to do from here? Cheers, - Ben

1 0