- ghc-devs - Haskell.org

Why do the reverse binder swap transformation?
by Rodrigo Mesquita 15 Jul '23

15 Jul '23

Dear GHC devs, I’m wondering about the reverse binder swap transformation, the one in which we substitute occurrences of the case binder by occurrences of the scrutinee (when the scrut. is a variable): case x of z { r -> e } ===> case x of z { r -> e[x/z] } My question is: why do we do this transformation? An example in which this transformation is beneficial would be great too. The Note I’ve found about it, Note [Binder-swap during float-out], wasn’t entirely clear to me: 4. Note [Binder-swap during float-out] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In the expression case x of wild { p -> ...wild... } we substitute x for wild in the RHS of the case alternatives: case x of wild { p -> ...x... } This means that a sub-expression involving x is not "trapped" inside the RHS. And it's not inconvenient because we already have a substitution. Note that this is EXACTLY BACKWARDS from the what the simplifier does. The simplifier tries to get rid of occurrences of x, in favour of wild, in the hope that there will only be one remaining occurrence of x, namely the scrutinee of the case, and we can inline it. Many thanks, Rodrigo

3 3

Exact-print info in the the HsSyn syntax tree
by Simon Peyton Jones 13 Jul '23

13 Jul '23

Dear GHC developers Could you please look at #23447 Where should "tokens" live <https://gitlab.haskell.org/ghc/ghc/-/issues/23447>? In brief, the question is whether we want to have: data HsExpr p = .... | HsLet (XLet p) (HsLocalBinds p) (LHsExpr p) or data HsExpr p = .... | HsLet (XLet p) (HsToken "let" p) (HsLocalBinds p) (HsToken "in" p) (LHsExpr p) In the former, if a client wants HsTokes to track the precise source locations of the "let" and "in" keywords, they'd have to put it in the TTG extension field; in the latter, this information is in *every* syntax tree. At the moment we have some of each, which is not satisfactory. We need to decide a policy and stick to it. If you use HsSyn, HsExpr, HsPat etc, in any way, you should have an opinion. Please do express it. At the moment we have only a few voices so we risk deciding without enough evidence and use-cases. Comments with specific use-cases and examples would be particularly helpful. Thanks! Simon

2 3

New spurious failure bot is running on GitLab
by Bryan Richter 13 Jul '23

13 Jul '23

Today I've deployed a new version of my retry service. I think I've worked out most of the kinks, so I'm going to leave it running overnight and see how it goes. In the worst case, it might crash and die, in which case spurious failures will not get retried until I come back and fix it tomorrow morning, Europe time. In the best case, the service will just keep doing what the old one did, with two improvements: 1. If the same job keeps failing, it will give up retries. 2. If sending a retry command to GitLab itself fails, those will also be retried a few times. -Bryan "Who retries the retryer?" - Juvenal, probably

1 0

Usage of Template Haskell quotes in GHC source tree vs. usage of GHC as a library
by Gergő Érdi 13 Jul '23

13 Jul '23

Hi, A recent commit 983ce55815f2dd57f84ee86eee97febf7d80b470 starts using TemplateHaskellQuotes in the GHC codebase. It seems this is at odds with using GHC as a library, a la ghc-lib. The `ghc-lib` approach is to basically take the module hierarchy from the `compiler/` subtree, and compile it as a completely vanilla Haskell library, with no direct attachment to the host GHC version. This enables using e.g. GHC 9.4 to compile a program using the GHC 9.6 API, and so on. In particular, it also makes it very easy to apply patches to the version of GHC used as a library, since in this setup it doesn’t need to be able to bootstrap. So what is the problem with using TemplateHaskellQuotes? The problem is the dependency on the template-haskell package. When a module inside GHC-as-a-library containing TH quotes is compiled, the quotes are translated into applications of the constructors defined by the *host* GHC’s TH package. But because GHC is tightly coupled to the TH support library, GHC-as-a-library needs to ship with its own internal version of the library. So the code that tries to process the results of these quotes is using the *target* GHC’s TH definitions. And that leads to a conflict: code like leftName :: Namel leftName = ‘Left is now a type mismatch between the type of `’Left` being template-haskell-2.19.0.0:Language.Haskell.TH.Syntax.Name (example when using GHC 9.4.5 as the host) and the type of `leftName` being ghc-lib-9.9.20230712:Language.Haskell.TH.Syntax.Name (example when the target version is built from recent `master`). Currently, `ghc-lib-gen` has a pre-processing step on the GHC source tree that replaces these quotations with applications containing direct references to the target TH constructors: https://github.com/digital-asset/ghc-lib/blob/ab01fb2b4d1e3a9338390e9c10ccd… but I am worried that this is very fragile. So any ideas on how to tackle this situation better? Thanks, Gergo

3 2

Can't build nofib
by Simon Peyton Jones 12 Jul '23

12 Jul '23

Friends With a clean HEAD I can't build nofib. See below. What should I do? Thanks Simon (cd nofib; cabal v2-run -- nofib-run --compiler=`pwd`/../_build/stage1/bin/ghc --output=`date -I`) Resolving dependencies... Error: cabal: Could not resolve dependencies: [__0] trying: nofib-0.1.0.0 (user goal) [__1] next goal: base (dependency of nofib) [__1] rejecting: base-4.18.0.0/installed-4.18.0.0 (conflict: nofib => base>=4.5 && <4.17) [__1] skipping: base-4.18.0.0, base-4.17.1.0, base-4.17.0.0 (has the same characteristics that caused the previous version to fail: excluded by constraint '>=4.5 && <4.17' from 'nofib') [__1] rejecting: base-4.16.4.0, base-4.16.3.0, base-4.16.2.0, base-4.16.1.0, base-4.16.0.0, base-4.15.1.0, base-4.15.0.0, base-4.14.3.0, base-4.14.2.0, base-4.14.1.0, base-4.14.0.0, base-4.13.0.0, base-4.12.0.0, base-4.11.1.0, base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0, base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, base-3.0.3.1 (constraint from non-upgradeable package requires installed instance) [__1] fail (backjumping, conflict set: base, nofib) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: base, nofib make: *** [/home/simonpj/code/Makefile-spj:39: nofib] Error 1

3 6

Call for Talks: Haskell Implementors' Workshop 2023 (deadline extension)
by Ryan Scott 11 Jul '23

11 Jul '23

TL;DR: The submission deadline for the 2023 Haskell Implementors' Workshop has been extended to June 16. ================================== ACM SIGPLAN Haskell Implementors' Workshop https://icfp23.sigplan.org/home/hiw-2023 Seattle, Washington, United States, September 4, 2023 Co-located with ICFP 2023 https://icfp23.sigplan.org/ Important dates --------------- Deadline: July 16, 2023 (AoE) (extended) Notification: August 4, 2023 Workshop: September 4, 2023 The 15th Haskell Implementors' Workshop is to be held alongside ICFP 2023 this year in Seattle. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure to share their work and to discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and short lightning talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2023. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides, and presented data available with the consent of the speakers. The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community are encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are especially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfp-hiw23.hotcrp.com until July 16 (anywhere on earth). We will also have a lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks should be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Program Committee ----------------- * Gergő Érdi (Standard Chartered Bank) * Sebastian Graf (Karlsruhe Institute of Technology) * Wen Kokke (University of Strathclyde) * Ryan Scott (Galois, Inc.) * Rebecca Skinner (Mercury) * Li-yao Xia (University of Edinburgh) Contact ------- * Ryan Scott <ryan.gl.scott at gmail.com>

1 1

JSON output of GHC Diagnostics
by Ben Bellick 10 Jul '23

10 Jul '23

Hey everyone, I am working on a summer of Haskell project to implement JSON output of GHC's diagnostics. I have begun working through some of the implementation details but have stumbled across a few road blocks and I wanted to get some feedback on. Discussion surrounding the plan can be found [here](https://github.com/haskellfoundation/tech-proposals/pull/50). In looking through the current implementation of the -ddump-json flag, I found a [note](https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Utils/L… which seems to indicate that a sensible (albeit invasive) approach is to alter the definition of [LogAction](https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Ut…, reproduced below: type LogAction = LogFlags -> MessageClass -> SrcSpan -> SDoc -> IO () So instead of taking in an SDoc, I could alter this signature to take a set of Diagnostics, though this may introduce other complications. In the first place, it seems log action is processing all of the diagnostics one at a time, though this particular JSON output should process all of them at once in order to place them all in a single JSON object. So, I am inclined to believe that this approach may not work. Another approach could be the one originally tried and mentioned in the note linked above, which is to keep track of all diagnostics in an IORef, and use this to produce a final JSON result at the end of GHC's execution. This approach seems invasive in a different way. Does anyone familiar with the handling of diagnostics throughout the compiler have any suggestions on how best to implement such a feature? You can find the work that I have done so far [here](https://gitlab.haskell.org/benbellick/ghc/-/compare/master...json-dia…. All I am really doing is checking if the new flag is set in [printMessages](https://gitlab.haskell.org/benbellick/ghc/-/compare/master..…. If it is, then I simply invoke the json function of the ToJson typeclass and use that to print the diagnostic. It is currently a bit messy, but I wanted to just see if the path that I am taking seems fruitful or if there are any obvious hurdles that I am not seeing. Thanks so much! Best, Ben Bellick

3 2

I can't build HEAD
by Simon Peyton Jones 10 Jul '23

10 Jul '23

in a clean HEAD build, including "git submodule update", I get this. Can anyone help? Simon | Run Ar Pack (Stage0 InTreeLibs): _build/stage0/libraries/ghc-heap/build/cmm/cbits/HeapPrim.o (and 15 more) => _build/stage0/libraries/ghc-heap/build/libHSghc-heap-9.9-inplace.a ar: creating _build/stage0/libraries/ghc-heap/build/libHSghc-heap-9.9-inplace.a /-----------------------------------------------------------------------------\ | Successfully built library 'ghc-heap' (Stage0 InTreeLibs, way v). | | Library: _build/stage0/libraries/ghc-heap/build/libHSghc-heap-9.9-inplace.a | | Library synopsis: Functions for walking GHC's heap. | \-----------------------------------------------------------------------------/ ]0;Running for 2m35s [2621/2966], predicted 47s (77%) ]0;Running for 2m40s [2621/2966], predicted 47s (77%) ]0;Running for 2m45s [2621/2966], predicted 47s (77%) | Run Ghc CompileHs (Stage0 InTreeLibs): libraries/containers/containers/src/Data/Sequence/Internal/Sorting.hs => _build/stage0/libraries/containers/containers/build/Data/Sequence/Internal/Sorting.o | Run GhcPkg Unregister (Stage0 GlobalLibs): process => none | Run GhcPkg Update (Stage0 InTreeLibs): _build/stage0/libraries/exceptions/inplace-pkg-config => none | Copy package 'exceptions' # cabal-copy (for _build/stage0/lib/package.conf.d/exceptions-0.10.7-inplace.conf) # cabal-configure (for _build/stage0/libraries/text/setup-config) | Run GhcPkg Recache (Stage0 InTreeLibs): none => none hadrian: Encountered missing or private dependencies: data-array-byte >=0.1 && <0.2 ]0;Finished in 2m47s ExitFailure 1 Build failed. make: *** [/home/simonpj/code/Makefile-spj:10: all] Error 1 simonpj@CDW-8FABODHF0V5:~/code/HEAD$

4 4

Re: I can't build HEAD
by Viktor Dukhovni 10 Jul '23

10 Jul '23

Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: On Sun, Jul 09, 2023 at 05:49:38PM +0100, Simon Peyton Jones wrote: > in a clean HEAD build, including "git submodule update", I get this. > > Can anyone help? Did you run "cabal update"? What is your boot compiler version? [...] Content analysis details: (5.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 5.0 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired language 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4970]

1 0

GitLab CI happenings in July
by Bryan Richter 03 Jul '23

03 Jul '23

Hello, This is the first (and, perhaps, last[1]) monthly update on GitLab CI. This month in particular deserves its own little email for the following reasons: 1. Some of the Darwin runners recently spontaneously self-upgraded, introducing toolchain changes that broke CI. All the fixes are now on GHC's master branch. This leaves us with two choices: A) Re-enable the affected runners now. All current patches will have a 50% of failing CI because the old problems are still present. Users (you) can rebase your patches to avoid this problem. B) Wait before re-enabling the runners. All in-flight MRs have a better chance of getting green CI and/or organically getting rebased for other reasons. However, Darwin capacity would remain at 50% for longer, slowing down all pipelines. My current plan is to wait one week before re-enabling the runners, but ultimately it's not my call. Opinions welcome. 2. I will be on vacation from July 17 to July 28 (weeks 29 and 30). Please tell Marge to be good while I am away. 3. GitLab was recently upgraded. Please do not be alarmed by any UI changes. Enjoy! -Bryan [1]: Intuitively, I like the idea of giving monthly updates about GitLab CI. But I don't know if it will be practical or valuable. I'll take a look in a month to see if there's anything notable to write about again.

1 0