January 2018 - ghc-devs

[ANNOUNCE] GHC 8.4.1-alpha1 available
by Ben Gamari 22 Jan '18

22 Jan '18

The GHC development team is pleased to announce the first alpha release of the 8.4.1 release. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.4.1-alpha1 Note that this release drops compatibility with GCC 4.6 and earlier. While we generally try to place as few constraints on system toolchain as possible, this release depends upon the __atomic__ builtins provided by GCC 4.7 and later (see #14244). === Notes on release scheduling === The 8.4.1 release marks the first release where GHC will be adhering to its new, higher-cadence release schedule [1]. Under this new scheme, major releases will be made in 6-month intervals with interstitial minor releases as necessary. In order to minimize the likelihood of schedule slippage and to ensure adequate testing, each major release will be preceeded by a number of regular alpha releases. We will begin issuing these releases roughly three months before the final date of the major release and will issue roughly one every two weeks during this period. This high release cadence will allow us to quickly get fixes in to users hands and allow better feedback on the status of the release. GHC 8.4 is slated to be released in mid-February but, due to technical constraints, we are starting the alpha-release cycle a bit later than planned under the above schedule. For this reason, it would be greatly appreciated if users could put this alpha through its paces to make up for lost time. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule

4 7

Extracting representation from GHC
by Németh Boldizsár 19 Jan '18

19 Jan '18

Dear GHC Developers, I would like to ask your opinion on my ideas to make it easier to use development tools with GHC. In the past when working on a Haskell refactoring tool I relied on using the GHC API for parsing and type checking Haskell sources. I extracted the representation and performed analysis and transformation on it as it was needed. However using the refactorer would be easier if it could work with build tools. To do this, my idea is to instruct GHC with a compilation flag to give out its internal representation of the source code. Most build tools let the user to configure the GHC flags so the refactoring tool would be usable in any build infrastructure. I'm thinking of using the pre-existing plugin architecture and adding two new fields to the Plugin datastructure. One would be called with the parsed representation (HsParsedModule) when parsing succeeds, another with the result of the type checking (TcGblEnv) when type checking is finished. What do you think about this solution? Boldizsár (ps: My first idea was using frontend plugins, but I could not access the representation from there and --frontend flag changed GHC compilation mode.)

5 5

RE: Why is EvTerm limited?
by Simon Peyton Jones 19 Jan '18

19 Jan '18

| What would break if we had | | | EvExpr CoreExpr | | as an additional constructor there? This has come up before. I think that'd be a solid win. In fact, eliminate all the existing evidence constructors with "smart constructors" that produce an EvExpr. That'd mean moving stuff from the desugarer into these smart constructors, but that's ok. I /think/ I didn't do that initially only because there were very few forms and it mean that there was no CoreExpr stuff in the type checker. But as we add more forms that decision looks and less good. You'd need to add zonkCoreExpr in place of zonkEvTerm. evVarsOfTerm is called quite a bit; you might want to cache the result in the EvExpr constructor. Make a ticket and execute? Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Joachim Breitner | Sent: 19 January 2018 14:01 | To: Glasgow-Haskell-Users users <glasgow-haskell-users(a)haskell.org> | Subject: Why is EvTerm limited? | | Hi, | | I had some funky idea where a type checker plugin would have to | synthesize code for a custom-solved instances on the fly. But it seems | that does not work because EvTerm is less expressive than Core | (especially, no lambdas): | https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloa | ds.haskell.org%2F~ghc%2F8.2.2%2Fdocs%2Fhtml%2Flibraries%2Fghc- | 8.2.2%2FTcEvidence.html%23t:EvTerm&data=02%7C01%7Csimonpj%40microsoft. | com%7C513ff7ae83914913225008d55f452dec%7C72f988bf86f141af91ab2d7cd011d | b47%7C1%7C0%7C636519673089385423&sdata=kFkUugVn02Nfu4QXJ6dkVwtx8KWFrTM | fWcVEiwf6KyI%3D&reserved=0 | | What would break if we had | | | EvExpr CoreExpr | | as an additional constructor there? | | Cheers, | Joachim | | -- | Joachim “nomeata” Breitner | mail(a)joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C513ff7ae839149 | 13225008d55f452dec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636519 | 673089385423&sdata=Vh4BvbeEVUBIntKcf3XEseOzwUTx2RHPuANTY328dpM%3D&rese | rved=0

1 0

Fwd: compiling GHC: undefined references
by Douglas Wilson 18 Jan '18

18 Jan '18

---------- Forwarded message ---------- From: Douglas Wilson <douglas.wilson(a)gmail.com> Date: Fri, Jan 19, 2018 at 5:23 PM Subject: Re: compiling GHC: undefined references To: Németh Boldizsár <nboldi(a)elte.hu> Hi Boldizsár, I infer from the path names that you are on windows? It's likely that you have not correctly configured your machine, since this commit passed validation on windows here: https://phabricator.haskell.org/B19134 Can you double check that you have followed the instructions here: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > Before the errors I have a warning: Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. > Call hs_init_ghc() from your main() function to set these options. > This is normal. > The only change I made is fixing some simple type errors in > utils/ghc-cabal/Main.hs that stopped compilation. > > It is very unusual for HEAD to fail to compile, and CI indicates that it does compiles on the test systems in this case. Good luck! Regards, Doug WIlson

1 0

compiling GHC: undefined references
by Németh Boldizsár 18 Jan '18

18 Jan '18

Dear GHC Devs, This is my first time trying to compile GHC on my machine and I need a little help to go on. I ran into a problem, I get a lot of undefined reference errors when linking. A sample of these: ghc\stage2\build\Main.o:fake:(.text+0x1f3): undefined reference to `ghczmprim_GHCziTypes_ZC_con_info' ghc\stage2\build\Main.o:fake:(.text+0x340): undefined reference to `ghczmprim_GHCziTypes_ZMZN_closure' ghc\stage2\build\Main.o:fake:(.text+0x498): undefined reference to `ghczmprim_GHCziTypes_False_closure' ghc\stage2\build\Main.o:fake:(.text+0x4c0): undefined reference to `ghczmprim_GHCziTypes_True_closure' Before the errors I have a warning: Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. The only change I made is fixing some simple type errors in utils/ghc-cabal/Main.hs that stopped compilation. Commit ID is: cf2c029ccdb967441c85ffb66073974fbdb20c20 Best Regards, Boldizsár

1 0

Versioning of libraries bundled with GHC pre-releases
by Ben Gamari 17 Jan '18

17 Jan '18

TL;DR. We propose to start following the PVP for core libraries shipped with GHC alpha release. Let us know what you think. Hello everyone, GHC has recently been reworking its release policy, increasing the release cadence to two releases per year. We hope that this change facilitates earlier and more thorough testing of GHC. Of course, a compiler is worth little if no real-world packages can be built with it. Historically library maintainers have been reluctant to offer releases claiming compatibility with pre-release GHCs due to the lax versioning guarantees offered by such pre-releases. Specifically, changes to libraries shipped with GHC pre-releases have historically not had proper distinct version numbers, causing unnecessary breakage for released code (e.g. [1]). To make maintainers feel more at ease with releasing libraries compatible with GHC alpha releases, we propose to start using the Package Versioning Policy (PVP) [2] to version GHC's core libraries with each alpha release. That is, libraries which are not source-identical will get at very least a minor bump with each alpha release. By "core libraries" we mean the set of: * base * template-haskell * integer-gmp * integer-simple * hpc * ghci * ghc-compact * all GHC dependencies not maintained by GHC HQ * ghc-prim * ghc-boot * ghc-boot-th Following the PVP will allow maintainers to safely release libraries to Hackage without fear that they will break when the final GHC 8.4.1 release is made, easing the testing process for everyone. If you have an opinion one way or another on this matter please do share it on this list. Cheers, - Ben [1] https://github.com/tibbe/hashable/issues/143 [2] https://pvp.haskell.org/

2 2

RE: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by Simon Peyton Jones 17 Jan '18

17 Jan '18

| Simon, we were wrong about CorePrep not dropping unfoldings for exported | ids, it really drops all unfoldings. I'd forgotten that. Notes are so useful! | Are there any other reasons for not doing this in CorePrep? Can we maybe | implement a pass before CorePrep just for cost center collection? Currently CorePrep is just in a unique-supply monad. But I guess you could add a writer monad to allow us to collect cost centres. That should not be hard. Alternatively, a separate pass (run only if we have profiling). I don’t feel strongly. A separate pass run always seems overkill somehow. Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 17 January 2018 06:54 | Subject: Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors | | #5889: -fno-prof-count-entries leads to linking errors | -------------------------------------+---------------------------------- | -------------------------------------+--- | Reporter: akio | Owner: bgamari | Type: bug | Status: new | Priority: highest | Milestone: 8.4.1 | Component: Compiler | Version: 8.3 | Resolution: | Keywords: | Operating System: Linux | Architecture: x86_64 | | (amd64) | Type of failure: GHC rejects | Test Case: | valid program | profiling/should_compile/T5889 | Blocked By: | Blocking: | Related Tickets: | Differential Rev(s): | Wiki Page: | | -------------------------------------+---------------------------------- | -------------------------------------+--- | | Comment (by osa1): | | Simon, we were wrong about CorePrep not dropping unfoldings for exported | ids, it really drops all unfoldings. There's a note | | {{{ | {- Note [Drop unfoldings and rules] | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | We want to drop the unfolding/rules on every Id: | | - We are now past interface-file generation, and in the | codegen pipeline, so we really don't need full unfoldings/rules | | - The unfolding/rule may be keeping stuff alive that we'd like | to discard. See Note [Dead code in CorePrep] | | - Getting rid of unnecessary unfoldings reduces heap usage | | - We are changing uniques, so if we didn't discard unfoldings/rules | we'd have to substitute in them | | HOWEVER, we want to preserve evaluated-ness; see Note [Preserve | evaluated-ness in CorePrep] | | Note [Preserve evaluated-ness in CorePrep] | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | We want to preserve the evaluated-ness of each binder (via | evaldUnfolding) for two reasons | | * In the code generator if we have | case x of y { Red -> e1; DEFAULT -> y } | we can return 'y' rather than entering it, if we know | it is evaluated (Trac #14626) | | * In the DataToTag magic (in CorePrep itself) we rely on | evaluated-ness. See Note Note [dataToTag magic]. | -} | }}} | | I can also clearly see that in the code we don't distinguish exported | from non-exported, we just zap all unfoldings (see `cpCloneBndrs` and | `zapUnfolding`). | | So it seems to me like we may have to collect cost centers before or | during CorePrep. I vaguely remember discussing this in the meeting and | one of the arguments against this was that `CorePrep` is already complex | enough so if possible it'd be nice to avoid making it even more complex. | Are there any other reasons for not doing this in CorePrep? Can we maybe | implement a pass before CorePrep just for cost center collection? | | -- | Ticket URL: | <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.hask | ell.org%2Ftrac%2Fghc%2Fticket%2F5889%23comment%3A29&data=02%7C01%7Csimonp | j%40microsoft.com%7C4c0906a7bcde47e7d7ac08d55d77108f%7C72f988bf86f141af91 | ab2d7cd011db47%7C1%7C0%7C636517688316807916&sdata=5eSk5giuvhClD%2BxskYvyc | f9qqTyYn%2Fwy3%2FxSuDoXMQA%3D&reserved=0> | GHC | <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.hask | ell.org%2Fghc%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C4c0906a7bcde47e | 7d7ac08d55d77108f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365176883 | 16817923&sdata=aandvbx2KYXpNrhNPodNIt%2FtxpY2yT4YytP0PTyIkDQ%3D&reserved= | 0> | The Glasgow Haskell Compiler

1 0

Are join points inlined differently from normal bindings?
by Matthew Pickering 16 Jan '18

16 Jan '18

I have quite a complicated program which relies on the optimiser inlining very aggressively. In 8.0.2, it works fine and produces the core I am expecting. In 8.2.2, one of the bindings is identified as a join point and then not inlined when doing so would lead to the same code. Bumping the unfolding-use-threshold to 10 (from 8) causes it to be inlined and produces the right core. Here is the core for reference - https://gist.github.com/mpickering/be30105b97fa7e4149c9fa935d72cd1c I haven't dug into which exact part of my program introduces this join point but this seems like a regression from 8.0.2. However, I make a mailing list post as I unsure how to expect the inliner to treat join points. Questions. 1. Does the inliner treat join point bindings differently to normal bindings? 2. How can I stop the compiler introducing this join point which seems to get in the way of the inliner? Cheers, Matt

2 1

RE: Implementing pattern synonym constructor signatures
by Simon Peyton Jones 16 Jan '18

16 Jan '18

0. Parsing. I wasn't actually able to find the code that parses pattern synonyms. Can someone point me in the right direction? Parser.y line 1356, production ‘patteron_synonym_decl’ looks plausible. Currently we have data HsPatSynDir id = Unidirectional | ImplicitBidirectional | ExplicitBidirectional (MatchGroup id (LHsExpr id)) so in the bidirectional case all we have a MatchGroup, built with mkPatSynMatchGroup. To serve the proposal we need an optional signature in there too. 1. When there is a constructor signature, it needs to be used for the construction function instead of the pattern signature. Can someone give point me in the right direction about how to do this? TcPatSyn.tcPatSynBuilderBind is a good place to start. 2. When there is a constructor signature but no pattern signature, what should we do? I think "give up" sounds okay for now. I don’t understand. Can you give an example? Simon From: David Feuer [mailto:david@well-typed.com] Sent: 15 January 2018 19:11 To: Simon Peyton Jones <simonpj(a)microsoft.com> Cc: ghc-devs(a)haskell.org Subject: Implementing pattern synonym constructor signatures Over the past week I've started digging into the code that implements pattern synonyms with an eye toward implementing the pattern synonym construction function signature proposal. I think I understand a decent amount of what's going on most places. However, I don't understand enough about type checking to have any idea about what needs to change where or how. There are several things that need to be addressed: 0. Parsing. I wasn't actually able to find the code that parses pattern synonyms. Can someone point me in the right direction? 1. When there is a constructor signature, it needs to be used for the construction function instead of the pattern signature. Can someone give point me in the right direction about how to do this? 2. When there is a constructor signature but no pattern signature, what should we do? I think "give up" sounds okay for now. 3. A pattern synonym without a constructor signature needs to be treated as it is today, so the machinery for matching things up needs to remain available. David Feuer Well-Typed, LLP

2 1

Implementing pattern synonym constructor signatures
by David Feuer 15 Jan '18

15 Jan '18

Over the past week I've started digging into the code that implements pattern synonyms with an eye toward implementing the pattern synonym construction function signature proposal. I think I understand a decent amount of what's going on most places. However, I don't understand enough about type checking to have any idea about what needs to change where or how. There are several things that need to be addressed: 0. Parsing. I wasn't actually able to find the code that parses pattern synonyms. Can someone point me in the right direction? 1. When there is a constructor signature, it needs to be used for the construction function instead of the pattern signature. Can someone give point me in the right direction about how to do this? 2. When there is a constructor signature but no pattern signature, what should we do? I think "give up" sounds okay for now. 3. A pattern synonym without a constructor signature needs to be treated as it is today, so the machinery for matching things up needs to remain available. David FeuerWell-Typed, LLP

2 3