January 2016 - ghc-devs

Warnings, -Wall, and versioning policy
by Simon Marlow 13 Jan '16

13 Jan '16

Hi folks, We haven't described what guarantees GHC provides with respect to -Wall behaviour across versions, and as a result there are some differing expectations around this. It came up in this weeks' GHC meeting, so we thought it would be a good idea to state the policy explicitly. Here it is: We guarantee that code that compiles with no warnings with -Wall ("Wall-clean") and a particular GHC version, on a particular platform, will be Wall-clean with future minor releases of the same major GHC version on the same platform. (we plan to put this text in the User's Guide for future releases) There are no other guarantees. In particular: - In a new major release, GHC may introduce new warnings into -Wall, and/or change the meaning of existing warnings such that they trigger (or not) under different conditions. - GHC may generate different warnings on different platforms. (examples of this are -fwarn-overflowed-literals and -fwarn-unsupported-calling-conventions) Some rationale: - We consider any change to the language that GHC accepts to be a potentially code-breaking change, and subject to careful scrutiny. To extend this to warnings would be a *lot* of work, and would make it really difficult to introduce new warnings and improve the existing ones. - Warnings can be based on analyses that can change in accuracy over time. The -fwarn-unused-imports warning has changed a lot in what it rejects, for example. - We often introduce new warnings that naturally belong in -Wall. If -Wall was required to be a fixed point, we would have to start introducing new flags, and versioning, etc. and even keep the old implementation of warnings when they change. It would get really messy. There are some consequences to this. -Wall -Werror is useful for keeping your code warning-clean when developing, but shipping code with these options turned on in the build system is asking for trouble when building your code with different GHC versions and platforms. Keep those options for development only. Hackage already rejects packages that include -Wall for this reason. One reason we're raising this now is that it causes problems for the 3-release policy (https://prime.haskell.org/wiki/Libraries/3-Release-Policy) which requires that it be possible to write code that is Wall-clean with 3 major releases of GHC. GHC itself doesn't guarantee this, so it might be hard for the core libraries committee to provide this guarantee. I suggest this requirement be dropped from the policy. Cheers, Simon

3 4

Reify and separating renamer+TH from type-checking
by Edward Z. Yang 13 Jan '16

13 Jan '16

I implemented the refactoring to run the renamer and TH splices all first before doing any type-checking, but actually there's a problem: Template Haskell splices can call 'reify', which needs the type information in order to supply the information about the identifiers in question. I can't think of any good way around this problem. Edward

5 4

Re: FW: Shaking up GHC
by Andrey Mokhov 12 Jan '16

12 Jan '16

Many thanks Eric, I think you solved the mystery! I changed my address on the ghc-devs mailing list from andrey.mokhov(a)ncl.ac.uk to andrey.mokhov(a)newcastle.ac.uk (it's the same mailbox really). Hopefully this will go through this time. Cheers, Andrey From: Eric Seidel <eric(a)seidel.io> To: ghc-devs(a)haskell.org Subject: Re: FW: Shaking up GHC I'm pretty sure you can only post to the list with the address you used to subscribe. According to https://mail.haskell.org/cgi-bin/mailman/roster/ghc-devs it looks like Andrey is subscribed with andrey.mokhov at ncl.ac.uk but the email you forwarded is from andrey.mokhov at newcastle.ac.uk So that may be the issue. Eric On Tue, Jan 12, 2016, at 08:20, Simon Peyton Jones wrote: > 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 >

1 0

Inlining of methods (dictionary accessors) in GHC 7.10?
by Conal Elliott 12 Jan '16

12 Jan '16

Did something about change with method inlining between GHC 7.8.2 and 7.10.3? I don't mean methods attached to instances, but rather the method name itself, which I understand is defined as simple field accessors into a dictionary. I do inlining indirectly via HERMIT, and the method names are no longer successfully inlining to the accessors. The dictionaries themselves inline fine, as do field accessors for algebraic types with named fields. -- Conal

3 4

Cabal status for GHC 8.0.1
by Ben Gamari 12 Jan '16

12 Jan '16

Hello everyone, As you likely know the GHC 8.0.1 release is quickly approaching. The release candidate should be out any moment now and we anticipate a final release in mid-February. Consequently, we should start thinking about how we will manage the Cabal release. Duncan has said that his nix-local-builds branch should be in good enough shape to be included as a technology preview with the GHC 8.0 release. Within what timeframe in particular do you think we'll be able to have a release tagged and (and ideally released)? Is late January possible? Cheers, - Ben

2 1

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 10 Jan '16

10 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