August 2014 - ghc-devs

Re: The formal definition of a crash in GHC
by Alexander Berntsen 22 Aug '14

22 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 28/02/14 13:41, Simon Peyton Jones wrote: > Crashing is usually formalised by the "progress" and "type > preservation" theorems that papers about statically-typed > programming languages usually offer. You will find many examples > of such theorems (and their proofs) in the papers about GHC's > intermediate language > http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/ > > A "crash" would mean that execution get stuck, and the progress > theorem guarantees that cannot happen. Would you, or anyone else, be able to make a wiki article on these theorems? So that we have a centralised resource that we can refer to. - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlP3Ip0ACgkQRtClrXBQc7WfAAD/VoQHW/bZLgdgoLCkSsLBGyIO B4F30jFLGuEB7NRvoIQBAKm0V4y2eutGUiSii0lTnzsP8Md3hKbZpUlcrqFmEQzf =OBHG -----END PGP SIGNATURE-----

1 0

Status of GHC targetting ARM?
by Iavor Diatchki 21 Aug '14

21 Aug '14

Hello, Does anyone have information about the status of GHC cross-compiling to ARM architectures? More specifically, I am interested in finding out what works and what still needs to be done before we can get GHC to generate binaries that can run on the various mobile platforms (Android, iOS). -Iavor

2 1

Status updates
by Austin Seipp 20 Aug '14

20 Aug '14

Hello *, Sorry for the scatter-brained-ness of my update. But without further ado, here are some things that have been going on: - I was going to land AMP, but I've gotten stuck again! It seems that now, Haddock infinite loops, but this one I really can't figure out. See my comment on the ticket[1] if you're adventurous - a small patch to Haddock and you should be able to build things, but it'll fail while Haddocking `ghc-prim`. Any help here would be much appreciated! - Phabricator now has significantly better build integration, as I'm sure many of you have seen. It is less noisy (and doesn't email you as much), has better logging support (that actually works), and it now builds commits AND patches! It's been in-production since last week and a lot more reliable than the crap I wrote before. I am thinking of changing the Phabricator GHC commit builder to validate all commits in `--slow` mode, which we can't do on Travis, and will catch more failures. I assume most people would approve of this. :) - The wiki has been updated in several spots: - The Phabricator page is now more detailed about Audits and more up to date about builds.[2] Yes, I know it looks long, but it's really just due to a lot of pictures. It's actually quite short still. - The Git workflow pages (starting from WorkingConventions/Git) have seen some minor updates[3], but nothing substantial. Some old pages still need to be deleted possibly, and some things (e.g. GitHub) might need further tweaks. - Yes, we're still seeing spam, but unfortunately nobody has had time to fix the CAPTCHAs yet. If you can write some python and want to, I'm sure Herbert would like to know. :) - There is a new status in Trac, primarily useful for patches, called 'upstream', which is very similar to 'patch', but says that the change goes to an upstream library that GHC must synchronize with. This difference is now much more important since many of our packages are tracked through submodules. See the working conventions page for some details and a pretty graph[4]. - I've gone ahead and split my old optimized-memcpy patch into two patches - D165 and D166 on Phabricator. Hopefully these will go in soon after some discussion with Johan about how we want to handle the flags is talked out. - All of the Phabricator patches from outstanding contributors have been merged, I think. There are some outstanding reviews still going on, and some accepted commits still waiting for other reviewers I believe. - Almost all of the current outstanding patches have been either merged, taken out of patch state (in case they were in limbo), or moved to 'upstream' status. Take a look at this wiki page: https://ghc.haskell.org/trac/ghc/query?status=patch&differential=&or&status… These are all the patches and upstream tickets, specifically those which do NOT have ongoing Phabricator code reviews for them. I chose this so we don't see tickets that may already be going under review elsewhere. Notably I'm testing the fusion tickets before merging them. OK, I think that's it. Do let me know if you have any questions (or would like to help with D13 :) [1] https://phabricator.haskell.org/D13#26 [2] https://ghc.haskell.org/trac/ghc/wiki/Phabricator [3] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git [4] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/BugTracker -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

Unifying inferred and declared *existential* type variables
by Dr. ERDI Gergo 20 Aug '14

20 Aug '14

Hi, Background: Type signatures for pattern synonyms are / can be explicit about the existentially-bound type variables of the pattern. For example, given the following definitions: data T where C :: (Eq a) => [a] -> (a, Bool) -> T pattern P x y = C x y the inferred type of P (with explicit foralls printed) is pattern type forall a. Eq a => P [a] (a, Bool) :: T My problem: Ticket #8968 is a good example of a situation where we need this pattern type signature to be entered by the user. So continuing with the previous example, the user should be able to write, e.g. pattern type forall b. Eq b => P [b] (b, Bool) : T So in this case, I have to unify the argument types [b] ~ [a] and (b, Bool) ~ (a, Bool), and then use the resulting coercions of the existentially-bound variables before calling the success continuation. So I generate a pattern synonym matcher as such (going with the previous example) (I've pushed my code to wip/T8584): $mP{v r0} :: forall t [sk]. T -> (forall b [sk]. Eq b [sk] => [b [sk]] -> (b [sk], Bool) -> t [sk]) -> t [sk] -> t [sk] $mP{v r0} = /\(@ t [sk]). \ ((scrut [lid] :: T)) ((cont [lid] :: forall b [sk]. Eq b [sk] => [b [sk]] -> (b [sk], Bool) -> t [sk])) ((fail [lid] :: t [sk])) -> case scrut of { C {@ a [ssk] ($dEq_aCt [lid] :: Eq a [ssk]) EvBindsVar<aCu>} (x [lid] :: [a [ssk]]) (y [lid] :: (a [ssk], Bool)) -> cont b $dEq_aCr x y |> (cobox{v} [lid], <Bool>_N)_N |> [cobox{v} [lid]]_N } <>} The two 'cobox'es are the results of unifyType'ing [a] with [b] and (a, Bool) with (b, Bool). So basically what I hoped to do was to pattern-match on 'C{@ a $dEqA} x y' and pass that to cont as 'b' and '$dEqB' by rewriting them with the coercions. (It's unfortunate that even with full -dppr-debug output, I can't see what's inside the 'cobox'es). However, when I try doing this, I end up with the error message SigGADT2.hs:10:9: Couldn't match type ‘a [ssk]’ with ‘b [sk]’ because type variable ‘b [sk]’ would escape its scope This (rigid, skolem) type variable is bound by the type signature for P :: [b [sk]] -> (b [sk], Bool) -> T at SigGADT2.hs:10:9 Expected type: [b [sk]] Actual type: [a [ssk]] Also, while the result of unifying '[b]' ~ '[a]' and '(b, Bool)' ~ '(a, Bool)' should take care of turning the 'a' bound by the constructor into the 'b' expected by the continuation function, it seems to me I'll need to do some extra magic to also turn the bound 'Eq a' evidence variable into the 'Eq b'. Obviously, I am missing a ton of stuff here. Can someone help me out? Thanks, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo(a)erdi.hu =-------' I love vegetarians - some of my favorite foods are vegetarians.

2 1

Windows build fails -- again!
by Simon Peyton Jones 20 Aug '14

20 Aug '14

Aaargh! My windows build is broken, again. It's very painful that this keeps happening. Can anyone help? Simon "inplace/bin/ghc-stage1.exe" -optc-U__i686 -optc-march=i686 -optc-fno-stack-protector -optc-Werror -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc-DRtsWay=\"rts_v\" -static -H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/Task.c -o rts/dist/build/Task.o cc1.exe: warnings being treated as errors rts\Capability.c:1080:6: error: no previous prototype for 'setIOManagerControlFd' rts/ghc.mk:236: recipe for target 'rts/dist/build/Capability.o' failed make[1]: *** [rts/dist/build/Capability.o] Error 1 make[1]: *** Waiting for unfinished jobs.... Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 HEAD (master)$

3 2

Partial recompilation of libraries
by David Feuer 19 Aug '14

19 Aug '14

I'd like to try out a bunch of little changes to the list stuff in base and get some nofib results for each change. Is there a way to do this without recompiling all of GHC each time?

2 1

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