July 2017 - ghc-devs - Haskell.org

Reinstallable lib:ghc (was: [core libraries] Upgradeable base (smallest step forward))
by Herbert Valerio Riedel 26 Jul '17

26 Jul '17

Hi everyone, As part of the recent GHC 8.2.1 release and the associated boot-library publishing to Hackage, I picked up again experimenting with a reinstallable lib:ghc package primarily for the benefit of uploading haddocks for lib:ghc (w/ `--hyperlinked-source`) to Hackage: http://hackage.haskell.org/package/ghc However, this also provides somewhat of a tech-preview of a reinstallable lib:ghc package, which would help mitigate a big issue we had in the past with lib:ghc and its dependencies being frozen to specific versions, and which in combination with cabal's nix-style pkg store that finally provide us with the ability to have multiple instances of the same library versions co-existing in the same package db, is no longer a requirement. So we could have lib:ghc more easily pick dependencies up (but still within reason!) like e.g. lib:text without forcing everyone to the single lib:text version bundled with GHC. And we'd also gain the ability to publish patch-level releases to lib:ghc only inbetween proper minor GHC releases (e.g. to support new versions of library dependencies). Consider this artificial example demo package which requires a different version of binary than the one bundled with GHC 8.2.1: --8<---------------cut here---------------start------------->8--- -- ghc-demo.cabal name: ghc-demo version: 0 build-type: Simple cabal-version: >=2.0 executable ghc-demo main-is: Main.hs build-depends: base ^>= 4.10, ghc ^>= 8.2.1, binary == 0.8.5.0 default-language: Haskell2010 --8<---------------cut here---------------end--------------->8--- Trying to build this will have the cabal solver complain that the installed instance of ghc requires a different (& installed) version of binary, i.e. binary-0.8.5.1. Moreover, the source version of lib:ghc on Hackage has the manual `buildable` cabal flag which defaults to false, and currently prevents lib:ghc to be reinstalled automatically (by enabling an unsatisfiable constraint): --8<---------------cut here---------------start------------->8--- Resolving dependencies... cabal: Could not resolve dependencies: trying: base-4.10.0.0/installed-4.1... (dependency of ghc-demo-0) next goal: ghc (dependency of ghc-demo-0) rejecting: ghc-8.2.1/installed-8.2... (conflict: binary==0.8.5.0, ghc => binary==0.8.5.1/installed-0.8...) trying: ghc-8.2.1 rejecting: ghc-8.2.1:-buildable (conflict: base==4.10.0.0/installed-4.1..., ghc -buildable => base<0) rejecting: ghc-8.2.1:+buildable (manual flag can only be changed explicitly) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: ghc-demo, binary, base, ghc, ghc-8.2.1:buildable --8<---------------cut here---------------end--------------->8--- However, if we unlock this by toggling the flag (NB: this only works on linux/x86_64; it's explained later why), e.g. --8<---------------cut here---------------start------------->8--- -- cabal.project file packages: . package ghc flags: +buildable --8<---------------cut here---------------end--------------->8--- The cabal solver would come up with an install-plan: --8<---------------cut here---------------start------------->8--- Resolving dependencies... Build profile: -w ghc-8.2.1 -O1 In order, the following will be built (use -v for more details): - binary-0.8.5.0 {binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac} (lib) (requires download & build) - ghc-boot-8.2.1 {ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb} (lib) (requires build) - ghci-8.2.1 {ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1} (lib) (requires build) - ghc-8.2.1 {ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c} (lib) +buildable (requires build) - ghc-demo-0 {ghc-demo-0-inplace-ghc-demo} (exe:ghc-demo) (first run) Configuring binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac (lib) Building binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac (lib) Installing binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac (lib) Finished binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac (lib) Configuring ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb (lib) Building ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb (lib) Installing ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb (lib) Finished ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb (lib) Configuring ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 (lib) Building ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 (lib) Installing ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 (lib) Finished ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 (lib) Configuring ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib) Building ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib) Installing ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib) Finished ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib) Configuring executable 'ghc-demo' for ghc-demo-0.. Preprocessing executable 'ghc-demo' for ghc-demo-0.. Building executable 'ghc-demo' for ghc-demo-0.. [1 of 1] Compiling Main ( Main.hs, /tmp/lll/dist-newstyle/build/x86_64-linux/ghc-8.2.1/ghc-demo-0/c/ghc-demo/build/ghc-demo/ghc-demo-tmp/Main.o ) Linking /tmp/lll/dist-newstyle/build/x86_64-linux/ghc-8.2.1/ghc-demo-0/c/ghc-demo/build/ghc-demo/ghc-demo ... --8<---------------cut here---------------end--------------->8--- So, cabal was able to succesfully produce an executable which uses a reinstalled lib:ghc w/ a different lib:binary version! But now for the limitations: this currently works at best with a GHC 8.2.1 installation whose configuration matches the generated files I manually included in the modified lib:ghc package in http://hackage.haskell.org/package/ghc-8.2.1/src/autogen/ which as you can see from the generated files (see e.g. Config.hs) was a Linux/x86_64/libgmp/internal-libffi/... configuration. ...and this finally brings me to the purpose of why I wrote this email: In order to make lib:ghc properly reinstallable we'd need to either a) have a way to regenerate the files autogen/* via a custom Setup.hs (by the likes of genprimcode or similiar) or the lazy option, b) simply have those files installed in a place we can easily locate (again, from a custom Setup.hs) Does this make any sense; which option do you prefer? Also, I'd like to know if you can think of reasons why or situations when the reinstalled lib:ghc wouldn't work; or other reasons why this is a bad idea. Cheers, hvr On 2016-06-05 at 19:02:29 +0200, Herbert Valerio Riedel wrote: >> As an ultimate goal for a project like this, it would be nice if you could >> do something like upgrade your base package but continue to use the ghc >> package without incompatible types. > > That's one way to approach this. However, I've been experimenting with a > more flexible way: Thanks to cabal-1.24's new nix-based tech-preview > which gets rid of that `--force-reinstall` abomination for good, the > prospect of simply recompiling the `ghc` cabal package becomes more > attractive. > > This would get rid of the primary reason which currently constraints us > to using the package versions bundled in GHC (like e.g. for > `bytestring`) as soon as `ghc` enters an install-plan. > > I'm still investigating this, but early experiments were promising, but > I need to reorganise GHC's source-tree a little bit to know for sure if > this is feasable. But if this as I hope is possible, this could open up > a lot of new possibilities!

3 2

Frontend Plugins Proposal
by Matthew Pickering 25 Jul '17

25 Jul '17

4 years ago Edsko proposed a patch to add support for frontend plugins to GHC. You can read his proposal here - https://ghc.haskell.org/trac/ghc/wiki/FrontendPluginsProposal#no1 Something like core to core plugins but for typechecked code would be useful for tool writers. Does anyone know why the patch was never merged? Confusingly Edward Yang implemented another feature called frontend plugins which does something quite different (allowing users to write custom major modes rather than hook into the frontend). These features are quite different to each other. Thanks, Matt

2 1

RE: D3754: Refactor uo_thing
by Simon Peyton Jones 24 Jul '17

24 Jul '17

Richard I'm on a train, so can't look at the detail. But the following thought occurs to me. uo_thing is a Maybe SDoc attached to a constraint. But a constraint also has a stack of [ErrCtxt], captured in the CtLoc. That's what produces the "In the declaration for ..." stuff. Idea: instead of uo_thing, could we just push an extra ErrCtxt onto the stack, in the CtLoc for this constraint? (Or not, in the Nothing case.) Simon From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 18 July 2017 19:39 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Differential] [Request, 533 lines] D3754: Refactor uo_thing goldfire created this revision. Herald added subscribers: thomie, rwbarton. Herald added a reviewer: hvr. View Revision<https://phabricator.haskell.org/D3754> REVISION SUMMARY The uo_thing field of TypeEqOrigin is used to track the "thing" (either term or type) that has the type (kind) stored in the TypeEqOrigin fields. Previously, this was sometimes a proper Core Type, which needed zonking and tidying. Now, it is only HsSyn: much simpler, and the error messages now use the user-written syntax. But this aspect of uo_thing didn't cause Trac #13819<https://ghc.haskell.org/trac/ghc/ticket/13819>; it was the sibling field uo_arity that did. uo_arity stored the number of arguments of uo_thing, useful when reporting something like "should have written 2 fewer arguments". We wouldn't want to say that if the thing didn't have two arguments. However, in practice, GHC was getting this wrong, and this message didn't seem all that helpful. Furthermore, the calculation of the number of arguments is what caused Trac #13819<https://ghc.haskell.org/trac/ghc/ticket/13819> to fall over. This patch just removes uo_arity. In my opinion, the change to error messages is a nudge in the right direction. Test case: typecheck/should_fail/T13819 TEST PLAN ./validate REPOSITORY rGHC Glasgow Haskell Compiler BRANCH wip/rae REVISION DETAIL https://phabricator.haskell.org/D3754 AFFECTED FILES compiler/ghci/RtClosureInspect.hs compiler/typecheck/Inst.hs compiler/typecheck/TcArrows.hs compiler/typecheck/TcErrors.hs compiler/typecheck/TcExpr.hs compiler/typecheck/TcHsType.hs compiler/typecheck/TcMType.hs compiler/typecheck/TcPat.hs compiler/typecheck/TcRnTypes.hs compiler/typecheck/TcSigs.hs compiler/typecheck/TcSplice.hs compiler/typecheck/TcSplice.hs-boot compiler/typecheck/TcTyClsDecls.hs compiler/typecheck/TcType.hs compiler/typecheck/TcUnify.hs compiler/typecheck/TcUnify.hs-boot compiler/types/Type.hs testsuite/tests/indexed-types/should_fail/T12867.stderr testsuite/tests/polykinds/T12593.stderr testsuite/tests/polykinds/T6039.stderr testsuite/tests/polykinds/T7278.stderr testsuite/tests/polykinds/T8616.stderr testsuite/tests/polykinds/T9200b.stderr testsuite/tests/rename/should_fail/rnfail026.stderr testsuite/tests/th/T3177a.stderr testsuite/tests/typecheck/should_fail/T11356.stderr testsuite/tests/typecheck/should_fail/T11672.stderr testsuite/tests/typecheck/should_fail/T12785b.stderr testsuite/tests/typecheck/should_fail/T13819.hs testsuite/tests/typecheck/should_fail/T13819.stderr testsuite/tests/typecheck/should_fail/T2994.stderr testsuite/tests/typecheck/should_fail/T3540.stderr testsuite/tests/typecheck/should_fail/T4875.stderr testsuite/tests/typecheck/should_fail/T7609.stderr testsuite/tests/typecheck/should_fail/T7778.stderr testsuite/tests/typecheck/should_fail/all.T testsuite/tests/typecheck/should_fail/tcfail070.stderr testsuite/tests/typecheck/should_fail/tcfail078.stderr testsuite/tests/typecheck/should_fail/tcfail113.stderr testsuite/tests/typecheck/should_fail/tcfail123.stderr testsuite/tests/typecheck/should_fail/tcfail132.stderr EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: goldfire, simonpj, austin, bgamari, hvr Cc: rwbarton, thomie, Mikolaj, fryguybob, carter, mpickering, adamgundry

2 1

Re: [GHC] #14005: Explore moving from pretty to prettyprinter
by Siddharth Bhat 22 Jul '17

22 Jul '17

Ben, Thank you for the fix :) However, the link appears to be broken? On Sat, 22 Jul 2017 at 23:15 GHC <ghc-devs(a)haskell.org> wrote: > #14005: Explore moving from pretty to prettyprinter > -------------------------------------+------------------------------------- > Reporter: bgamari | Owner: (none) > Type: task | Status: new > Priority: normal | Milestone: 8.4.1 > Component: Compiler | Version: 8.0.1 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): Phab:D3650 > Wiki Page: | > wiki:PrettyErrors | > -------------------------------------+------------------------------------- > > Comment (by bgamari): > > For the record, my > [[ > https://github.com/bgamari/ghc/commit/5256c89d3172d353d4ebc595b8c38c7ae5a79… > ]] > contains a rather hacky fix for this in issue (at least in the case of the > NCG). > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14005#comment:8> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler > -- Sending this from my phone, please excuse any typos!

1 0

Repeated computations under a lambda
by Conal Elliott 19 Jul '17

19 Jul '17

I'm seeing what looks like repeated computation under a lambda with `-O` and `-O2`. The following definition: > exampleC :: Double -> Double -> Double > exampleC = \ t -> let s = sin t in \ x -> x + s yields this Core: > -- RHS size: {terms: 13, types: 6, coercions: 0} > exampleC :: Double -> Double -> Double > exampleC = > \ (t_afI6 :: Double) (eta_B1 :: Double) -> > case eta_B1 of _ { D# x_aj5c -> > case t_afI6 of _ { D# x1_aj5l -> > D# (+## x_aj5c (sinDouble# x1_aj5l)) > } > } The `sinDouble#` here depends only on `t_afI6` (`t`) but still appears under the binding of `eta_B1` (`x`). I'm concerned because many of my uses of such functions involve computations dependent only on `t` (time) but with millions of uses (space) per `t`. (I'm working on a GHC Core plugin (compiling to categories), with one use generating graphics GPU code.) Does the optimization I expected somehow happen later in the compilation pipeline? Are there Core-manipulating functions in GHC that I can use to make it happen earlier (via a `BuiltinRule`, i.e., Core-to-Core function)? Thanks, -- Conal

5 11

Proposed: Language.Haskell.TH.Internal
by Richard Eisenberg 18 Jul '17

18 Jul '17

Hi devs, This is a brief proposal for an internal, non-user-facing restructuring of the implementation of Template Haskell. It's here (instead of at ghc-proposals) because it's not user-facing. When a user writes a TH quote [| foo bar baz |], GHC must desugar that into some Core code that builds a Q Exp. This is currently done by calling functions in Language.Haskell.TH.Lib, which is capable of building all the TH abstract syntax. However, many end-users of TH *also* import Language.Haskell.TH.Lib and use its functions. This means that, as the Haskell AST evolves, we can't reasonably evolve this Lib module, as it breaks user code. (There is a requisite amount of churn in TH, but we try to avoid gratuitous changes in Lib.) This has bitten in the past when we have, say, changed the representation of type families to accommodate closed type families, and it's biting now as we (ahem, Ryan Scott) are trying to merge types and kinds in TH. I thus propose a new module Language.Haskell.TH.Internal. This will start out as a slimmed-down copy of Lib (slimmed-down because Lib already has a bunch of now-disused functions) but may evolve independently. Desugaring quotes will go via this new Internal module, and we will have no qualms about changing its interface, as it's Internal. What do we think? Ryan has already implemented this idea in D3751. Pros: - Flexibility - Separation between user-facing interface and internal interface Cons: - More stuff - We already break the TH API with every release; maybe it's not so bad to break more of it. Thanks, Richard

3 2

Re: Which stable GHC release is expected to have support for linear types?
by Edvard Hübinette 15 Jul '17

15 Jul '17

Hi Wolfgang, I've put together a small README for getting this up and running (both for using stack with pre-built Docker images, and from source). It can be found in the repository here: https://github.com/tweag/ghc/tree/linear-types. Hope this will help! Cheers, Edvard Hübinette

7 21

GHCi tests hanging on Mac
by Richard Eisenberg 14 Jul '17

14 Jul '17

Hi devs, Some GHCi tests (but far from all!) hang on my Mac. I can't reproduce this behavior outside the testsuite driver, so I think it's the Python code, not the Haskell. Failing tests: ghci/prog017/prog017 ghci/scripts/T6018ghcifail ghci/scripts/T6018ghcirnfail And that's it! My Python reports that it's 2.7.13. Any leads to follow? Thanks, Richard

2 1

Trac down for a bit
by Ben Gamari 12 Jul '17

12 Jul '17

Hello everyone, Sorry for the interruption but Trac is having some trouble at the moment. I'm actively working on restoring service and will let you know when things are back to normal. Cheers, - Ben

1 1

Building GHC reference manual?
by Iavor Diatchki 11 Jul '17

11 Jul '17

Hello, is it possible to build just the HTML for the GHC reference manual, without building the whole of GHC, and if so how do I do it? -Iavor

3 2