- ghc-devs - Haskell.org

Nested CPR patch review
by Matthew Pickering 29 Jan '18

29 Jan '18

Hi all, I recently resurrected akio's nested cpr branch and put it on phabricator for review. https://phabricator.haskell.org/D4244 Sebastian has kindly been going over it and ironed out a few kinks in the last few days. He says now that he believes the patch is correct. Is there anything else which needs to be done before merging this patch? Simon, would you perhaps be able to give the patch a look over? Cheers, Matt

3 5

https://downloads.haskell.org/~ghc/master/
by Joachim Breitner 28 Jan '18

28 Jan '18

Hi, just curious: What is the status of https://downloads.haskell.org/~ghc/master/ where I would expect the documentation of GHC HEAD? It seems to be last updated in October, and also be missing the GHC API docs. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

GHC builds are broken
by David Feuer 27 Jan '18

27 Jan '18

The Linux build has been failing with a segfault. It looks to me as though this started with 0e022e56b130ab9d277965b794e70d8d3fb29533: Turn EvTerm (almost) into CoreExpr.

3 3

Re: [ANNOUNCE] GHC 8.4.1-alpha2 available
by Ryan Scott 25 Jan '18

25 Jan '18

Forgive me if I'm stating the obvious here, but the status of libraries like primitive, unordered-containers, and haskell-src-exts don't really have anything to do with GHC, since they're independent libraries that aren't shipped with GHC in any way. If you're impatient to use the Haskell library ecosystem with GHC 8.4.1, I highly encourage you to use a solution like head.hackage [1], as many library authors are not as much of early adopters as we are :) Ryan S. ----- [1] https://github.com/hvr/head.hackage

1 0

[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 19 Jan '18

19 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 19 Jan '18

19 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