- ghc-devs - Haskell.org

FW: Shaking up GHC
by Simon Peyton Jones 12 Jan '16

12 Jan '16

Dear ghc devs Can someone figure out how to help Andrey be able to post to this mailing list (ghc-devs)? I thought anyone subscribed can post, but perhaps not. Thanks! Simon From: Andrey Mokhov [mailto:andrey.mokhov@newcastle.ac.uk] Sent: 12 January 2016 14:49 To: Simon Peyton Jones <simonpj(a)microsoft.com> Cc: Neil Mitchell <ndmitchell(a)gmail.com>; Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Subject: RE: Shaking up GHC Hi Simon, Happy New Year! Indeed, as soon as my teaching was over I jumped on the project with double energy, and then several people joined as collaborators, so we are in a very good shape right now. I'm happy with the progress. We can already build GHC on Windows/Linux/OSX from scratch without relying on the old build system, but with some limitations (only vanilla way, no validation, command line flags not supported). Feel free to try! We are getting close to the first milestone `first-shake`: https://github.com/snowleopard/shaking-up-ghc/milestones. It should be ready in a week, and I think it would be a perfect timing to announce it on GHC devs mailing list. The only problem: I still can't post to the GHC devs mailing list. I tried several times, sent several requests to ghc-devs-owner(a)haskell.org<mailto:ghc-devs-owner@haskell.org> to whitelist my email, but no luck so far. Would you be the owner by any chance? Please let me in! :-) As soon as `first-shake` is released I'll start writing the ICFP paper. Thanks for pushing and willing to be a co-author! Cheers, Andrey From: Simon Peyton Jones [mailto:simonpj@microsoft.com] Sent: 12 January 2016 11:02 To: Andrey Mokhov Cc: Neil Mitchell; Simon Peyton Jones Subject: Shaking up GHC Andrey I’ve seen a few issue messages from #147 https://github.com/snowleopard/shaking-up-ghc (it says “you are receiving notifications because you were mentioned”). And I saw Neil yesterday. So it looks as though you are tremendously active and, better still, have several other collaborators. That’s fantastic! Would you like to send an update message to the GHC devs mailing list, to keep us all up to date? • what you are doing • who is involved • what help (if any) you want; e.g. alpha-testers • what you plan Finally, what about a paper for ICFP or, if rejected, the Haskell Symposium. I really want to get this written up, and ICFP is a useful forcing function. But you’d need to start writing now! I’d be a willing co-author. Happy new year! Simon

2 1

Pattern match checking
by Simon Peyton Jones 12 Jan '16

12 Jan '16

George I believe that your #1 priority on the GHC pattern matching front is to make it so that the pattern checker will give up if it examines more than 1,000 (or whatever, there should be a settable limit) cases in the pruner. This should cure all the performance problems at once, at the cost of giving up on the exhaustiveness check for that function. This is a small, local, single change; should not take long. When do you think you’ll be done with that? I am (very) ambitious to do a better job, and we discussed various approaches. But the First Thing is to stop GHC consuming infinite time. Thanks! Simon

1 0

Injective type families
by Ben Gamari 12 Jan '16

12 Jan '16

Hi Jan, A few questions came up this morning while speaking Andres Loeh about injective type families: 1. Should this feature be placed behind a LANGUAGE pragma? Afterall, functional dependencies feel very similar and in this case we require a pragma. Now would be the last opportunity to change this. 2. Could you perhaps add some text to better motivate the feature in the users guide? Referring to the paper for the details of semantics of the feature and its implementation is fine, but expecting a new user to refer to the paper to even know *why* they might want to use it seems a bit unfriendly. Thanks! Cheers, - Ben

5 12

Phab not running a full validate?
by Richard Eisenberg 12 Jan '16

12 Jan '16

Hi devs, Take a look at https://phabricator.haskell.org/harbormaster/build/9990/ See how only 1 test was run. Is this expected? Does Phab now bail when it runs into an error? Or have I done something wrong? Thanks, Richard

3 2

Flag warnings show intermediate hscpp filenames on SmartOS
by Alain O'Dea 11 Jan '16

11 Jan '16

On SmartOS GHC flag warnings show up like this: /tmp/ghc72341_0/ghc_1.hscpp:7:16: Warning: -fffi is deprecated: use -XForeignFunctionInterface or pragma {-# LANGUAGE ForeignFunctionInterface #-} instead It appears that this line in DriverPipeline leads to the correct filename in warnings on Ubuntu, but not on SmartOS: src_opts <- liftIO $ getOptionsFromFile dflags0 output_fn https://github.com/ghc/ghc/blob/bb7f2e33197e667eb694bd1243f125c722a0a868/co… How does the intermediate hscpp filename get restored to a correct filename if warnings are generated during a re-read of the pragmas after having preprocessed the file? Full investigation notes are here (rambling and unedited): https://gist.github.com/AlainODea/98141991849093285c52

3 16

cpphs: can't be used to build GHC 7.10.3. Bug?
by Alain O'Dea 10 Jan '16

10 Jan '16

Hi Malcolm: cpphs is under consideration as a replacement for GCC's C preprocessor in the GHC toolchain: https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp GHC 7.10.3's build fails when cpphs is used as the C preprocessor (--with-hs-cpp=cpphs --with-hs-cpp-flags="--cpp"). It runs into this error when preprocessing libraries/base/GHC/Natural.hs: cpphs: macro MIN_VERSION_integer_gmp expected 3 arguments, but was given 0 I've reproduced this issue on Ubuntu 14.04 x86-64 and SmartOS 15.3.0 x86-64. Interestingly the error seems to arise only when preprocessing Natural.hs while the autogenerated cabal-macros.h is present. Removing that include from the cpphs flags leads to a clean preprocessing run. I have more details of this investigation here: https://gist.github.com/AlainODea/bd5b3e0e6f7c4227f009 Is this a bug? Best, Alain

2 4

NOINLINE effects worker/wrapper - why and how to fix?
by Ömer Sinan Ağacan 09 Jan '16

09 Jan '16

So I was doing some micro benchmarks and I realized that adding NOINLINE to a function somehow prevents worker/wrapper. Imagine this factorial function which has a very obvious worker/wrapper opportunity: fac :: Int -> Int fac 0 = 1 fac n = n * fac (n - 1) If I add NOINLINE to this, no matter what -O I use, I get this STG: fac = \r srt:SRT:[] [ds_s38j] case ds_s38j of _ { I# ds1_s38l -> case ds1_s38l of ds2_s38m { __DEFAULT -> case -# [ds2_s38m 1#] of sat_s38n { __DEFAULT -> let { sat_s38o = NO_CCS I#! [sat_s38n]; } in case fac sat_s38o of _ { I# y_s38q -> case *# [ds2_s38m y_s38q] of sat_s38r { __DEFAULT -> I# [sat_s38r]; }; }; }; 0# -> lvl_r38f; }; }; Which doesn't have worker/wrapper. When I remove NOINLINE I get this worker/wrappered version as expected: $wfac = \r srt:SRT:[] [ww_s38W] case ww_s38W of ds_s38X { __DEFAULT -> case -# [ds_s38X 1#] of sat_s38Y { __DEFAULT -> case $wfac sat_s38Y of ww1_s38Z { __DEFAULT -> *# [ds_s38X ww1_s38Z]; }; }; 0# -> 1#; }; fac = \r srt:SRT:[] [w_s390] case w_s390 of _ { I# ww1_s392 -> case $wfac ww1_s392 of ww2_s393 { __DEFAULT -> I# [ww2_s393]; }; }; I'd expect to get the same with NOINLINE too. First of all, I think this suggests that if my function is big enough (or has some other property and GHCs heuristics decide not to inline) I don't get worker/wrapper. Second, this type of NOINLINEs are very useful for a couple of reasons. For example, let's say I'm benchmarking a function, I NOINLINE the function because I don't want the function to be transformed to something else during the benchmarking, because of inlining and interactions of the function code with the code at the call site (the code that benchmarks). Another example is when looking at the code to see if expected optimizations are done by GHC. I NOINLINE because otherwise I may have to look at dozens of call sites, rather than just one place (the definition). But now I can't reliably do that. So my questions are: Why worker/wrapper is not applied to NOINLINE functions, and how do I fix this? Thanks.

1 0

Re: How does TH know to load non-profiled object code when compiling profiled?
by Edward Z. Yang 08 Jan '16

08 Jan '16

Thanks! In fact, I have just realized that Template Haskell does something very dodgy when it is loading profiled code: it will use the *profiled* interface files (things that are used in splices are brought into scope with import) to figure out what is going on with the *non-profiled* object files. I'm a bit surprised that we haven't had any terrifying bugs related to this. (It should be relatively easy to trigger horrible brokenness; just compile hi and p_hi with different code so that they are inconsistent.) Edward Excerpts from Simon Marlow's message of 2016-01-07 09:42:27 -0800: > On 07/01/2016 16:28, Edward Z. Yang wrote: > > I've been looking for the code that implements this logic, but I can't > > seem to find it. (For what it's worth, compiler plugins *incorrectly* > > load the profiling interface when compiling profiled, which is wrong > > and something I'd like to fix.) Simon Marlow, do you happen to know? > > Yeah, I've been fiddling with this lately. It's this function here: > https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/ghci/L… > > Cheers, > Simon

2 1

Remote GHCi
by Simon Marlow 08 Jan '16

08 Jan '16

Hi folks - I've been thinking about changing the way we run interpreted code so that it would be run in a separate process. It turns out this has quite a few benefits, and would let us kill some of the really awkward hacks we have in GHC to work around problems that arise because we're running interpreted code and the compiler on the same runtime. I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi I'd be interested to hear if anyone has any thoughts around this, particularly if doing this would make your life difficult in some way. Are people relying on dynCompileExpr for anything? Cheers, Simon

9 27

Confused about specified type variables using -XTypeApplications
by Ryan Scott 08 Jan '16

08 Jan '16

I read in the Visible Type Applications paper [1] that you can only apply types to "specified" type variables. However, after trying out -XTypeApplications, I'm confused as to what exactly that means: $ /opt/ghc/head/bin/ghci GHCi, version 8.1.20160106: http://www.haskell.org/ghc/ :? for help λ> :set -XTypeInType -XTypeApplications λ> data Prox a = Prox λ> let prox :: Prox a; prox = Prox λ> :t prox @Int prox @Int :: Prox Int λ> :t Prox @Int Prox @Int :: Prox a Huh? For some reason, I'm getting different types for prox @Int and Prox @Int! I think what's happening here is that in Prox @Int, the Int is being applied to a kind variable. That is, it's being applied to the k variable in: Prox :: forall k (t :: k). Prox t But why is this? After all, I don't think I "specified" k anywhere in the definition of Prox, and to make things more confusing, Int gets applied differently in prox @Int (and the definition of prox also doesn't mention k). Is this a bug, or am I misunderstanding something about -XTypeApplications? Ryan S. ----- [1] http://www.cis.upenn.edu/~eir/papers/2016/type-app/visible-type-app.pdf

4 5