- ghc-devs - Haskell.org

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

Simon's (lack of) input
by Simon Peyton Jones 11 Jul '17

11 Jul '17

Friends My GHC inbox has grown to alarming proportions. I try to keep abreast of tickets where I think I have something substantial contribute, and generally succeed, but I've been failing badly in the last few weeks because of a storm of other commitments. I'll get back to it, but probably not before my summer holiday 3-17 August. Meanwhile if you are stalled awaiting input from me, please feel free to ping me about it. Simon

1 0