- ghc-devs - Haskell.org

Testsuite tests
by Simon Peyton Jones 08 Apr '25

08 Apr '25

Friends In CI for !10479 I'm getting test failures for some call-stack tests e.g. `callstack001`. But if I try to run this in my build tree hadrian/build -j8 test --skip=_build/stage1/rts/** --skip=_build/stage1/** --skip=_build/stage0/** --docs=none --only=callstack001 I get SUMMARY for test run started at Fri Apr 4 22:22:47 2025 0:00:02.413942 spent to go through 1 total tests, which gave rise to 8 test cases, of which 8 were skipped 0 had missing libraries 0 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 0 unexpected failures 0 unexpected stat failures 0 fragile tests So I can't reproduce the failure. What am i doing wrong? Can anyone help? Thanks Simon

2 3

Next steps forward for a stable Template Haskell
by Teo Camarasu 08 Apr '25

08 Apr '25

Hi folks, At Tuesday's GHC devs meeting, we talked about having a discussion about template-haskell stability. I've jotted down some notes to help focus our future discussion. It's mostly just a list of what I take to be the next most important issues to tackle, and some details about each. https://docs.google.com/document/d/1gui1YXOvrNihR3NpXuMVCKV3lTkKPL8y_HDRjbZ… Cheers, Teo

3 3

Extended deadline - CFP - Haskell Implementors' Workshop 2025
by Andreas Herrmann 07 Apr '25

07 Apr '25

Extended deadline to April 18, 2025 Call for proposals for the Haskell Implementors' Workshop https://haskell.foundation/events/2025-haskell-implementors-workshop.html June 6, 2025 Organized by the Haskell Community Co-located with ZuriHac 2025 and Haskell Ecosystem Workshop 2025 Hosted by the Haskell Foundation at Eastern Switzerland University of Applied Sciences (OST) https://www.ost.ch/en/university-of-applied-sciences/campus/rapperswil-jona… ## Overview * Extended Deadline: April 18, 2025 * Notification: May 5, 2025 * Workshop: June 6, 2025 The 17th Haskell Implementors' Workshop is to be held alongside ZuriHac 2025 this year near Zurich. 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 lightning talks. In the past the Haskell Implementors’ Workshop was co-located with ICFP (International Conference on Functional Programming). However, in recent years it has become more and more challenging to attract a large enough audience and sufficiently many speakers for an appealing program. ZuriHac and the Haskell Ecosystem Workshop have become an important annual gathering of a large part of the Haskell community. This year the Haskell Implementors’ Workshop will be co-located with these events to be accessible to a broader audience. ## Scope and Target Audience The Haskell 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, optimization 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. Submissions can be made via the form linked below until April 18, 2025 (anywhere on earth). https://docs.google.com/forms/d/e/1FAIpQLSdczGbxJYGc4eusvPrxwBbZl561PnKeYno… We will also have a lightning talks session. 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 * Luite Stegeman * Jaro Reinders * Emily Pillmore * Rodrigo Mesquita * Ian-Woo Kim * Andreas Herrmann (chair) ## Contact * Andreas Herrmann

1 0

Late CC profiling
by Simon Peyton Jones 07 Apr '25

07 Apr '25

Hi Matthew, Andreas, Ben In GHC today there is a strange inconsistency: - Bindings for data constructor wrappers and class method selectors are added at the end of CoreTidy. - Bindings for data constructor workers are added at the start of CorePrep This is deeply strange. In !10479 (unary class patch) <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10479> I had to make some changes in this area and after being baffled I moved all these implicit bindings to one place at the start of CorePrep. That is simpler and neater. There is no reason for them to be separate. BUT I find that one thing happens between Tidy and Prep, namely late-cost-centre injection. That means we will no longer get late-cost-centres for data constructor wrappers and class method selectors. I think that this is what is causing diffs in the output for callstack001 and friends in !10479. I think that this is perfectly fine, and I propose to accept the changes. Another alternative would be to inject all of these bindings at the end of Tidy (instead of the start of Prep), But it's much nicer at the start of Prep -- we don't want any of these bindings to appear in interface files. Can you confirm that the change is ok? Thanks Simon

3 4

GHC memory usage when typechecking from source vs. loading ModIfaces
by Gergő Érdi 03 Apr '25

03 Apr '25

Hi, I’m using the GHC API to typecheck 35,000 modules that form a complicated dependency graph (with multiple top-level modules, i.e. there’s no single “god module” that would transitively depend on everything else), and I noticed that peak memory usage is wildly different when everything is done from scratch vs. when everything is loaded from files containing ModIfaces: 17G vs. 8G. This ratio replicates for smaller samples as well, e.g. 80M vs 33M for 407 modules. I’m aware of https://gitlab.haskell.org/ghc/ghc/-/issues/13586 and so when I finish typechecking a module, I take the resulting ModIface and create the ModDetails that ends up in the HomeUnitGraph from that. My understanding of Matt’s original GHC fix in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5478 is that it does the same, i.e. it only makes a fresh ModDetails only once per module, after the ModIface is ready. But of course that still means that ModDetails can only keep growing as more and more parts of it are used for typechecking more and more dependants. Could that be the cause? I tried a crude experiment of “putting the toothpaste back in the tube” by replacing all ModDetails with a fresh one in the HUG after each finished typechecking , but that’s a complete disaster for memory usage: even for the small 407 module example, the memory usage shoots up to 1.5G. I can imagine it’s because imported Ids are probably not shared anymore between different importer modules. Any ideas on how I could improve memory usage in the from-scratch case, so that it's more similar to the from-ModIface case? Thanks, Gergo

5 30

gitlab.haskell.org reboot this evening
by Ben Gamari 01 Apr '25

01 Apr '25

Hi all, As part of finalizing the migration I will be rebooting gitlab.haskell.org at 17:00 EDT today. I expect the outage will last around 5 minutes. Cheers, - Ben

1 0

gitlab.haskell.org outage this weekend
by Ben Gamari 30 Mar '25

30 Mar '25

Hi all, As you may know, Haskell.org is currently in the process of moving its infrastructure to new hosting facilities. As part of this effort, GHC's GitLab instance will be taken down for migration on Saturday 29 March 2025 from 09:00 to 17:00. This includes our issue tracker, CI infrastructure, Docker registry, serving of artifacts. Apologies for the inconvenience but we hope that this will be the last time we need to have such a prolonged outage in quite a while. Cheers, - Ben

1 2

CFP - Haskell Implementors' Workshop 2025
by Andreas Herrmann 27 Mar '25

27 Mar '25

Call for proposals for the Haskell Implementors' Workshop https://haskell.foundation/events/2025-haskell-implementors-workshop.html June 6, 2025 Organized by the Haskell Community Co-located with ZuriHac 2025 and Haskell Ecosystem Workshop 2025 Hosted by the Haskell Foundation at Eastern Switzerland University of Applied Sciences (OST) https://www.ost.ch/en/university-of-applied-sciences/campus/rapperswil-jona… ## Overview * Deadline: April 4, 2025 * Notification: May 5, 2025 * Workshop: June 6, 2025 The 17th Haskell Implementors' Workshop is to be held alongside ZuriHac 2025 this year near Zurich. 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 lightning talks. In the past the Haskell Implementors’ Workshop was co-located with ICFP (International Conference on Functional Programming). However, in recent years it has become more and more challenging to attract a large enough audience and sufficiently many speakers for an appealing program. ZuriHac and the Haskell Ecosystem Workshop have become an important annual gathering of a large part of the Haskell community. This year the Haskell Implementors’ Workshop will be co-located with these events to be accessible to a broader audience. ## Scope and Target Audience The Haskell 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, optimization 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. Submissions can be made via the form linked below until April 4, 2025 (anywhere on earth). https://docs.google.com/forms/d/e/1FAIpQLSdczGbxJYGc4eusvPrxwBbZl561PnKeYno… We will also have a lightning talks session. 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 * Luite Stegeman * Jaro Reinders * Emily Pillmore * Rodrigo Mesquita * Ian-Woo Kim * Andreas Herrmann (chair) ## Contact * Andreas Herrmann

1 1

GHC 9.6.7 is now available
by Luite Stegeman 25 Mar '25

25 Mar '25

The GHC developers are very pleased to announce the availability of GHC 9.6.7. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.6.7 We hope to have this release available via ghcup shortly. GHC 9.6.7 brings number of fixes, including: - GHC’s internal Unique type has been widened to 64-bits on 32-bit architectures, avoiding potential miscompilations on large projects. - Fix a runtime crash when using the compacting GC, caused by black holes in large objects. - Added new flags -fspec-eval and -fspec-eval-dictfun to allow switching off speculative evaluation. The following libraries have been updated since GHC 9.6.6: - base-4.18.3.0 - filepath-1.4.301.0 - unix-2.8.6.0 - bytestring-0.11.5.4 - array-0.5.8.0 A more detailed description can be found in the [release notes] and a full list of changes in [GHC!13841] and [GHC!13891] Note about Haskell Language Server and building GHC 9.8+: The change of Unique to 64 bit [GHC#22010] adds the exported symbol ghc_unique_counter64 to the RTS. Unfortunately it's impossible to avoid this without breaking other things. If you encounter a linker error related to ghc_unique_counter64 when building GHC (or building a GHC-derived package like ghc-lib-parser) with GHC 9.6.7, you probably have to add this [fix] to the program you're building. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. Please give this release a try and open a [ticket] if you see anything amiss. ~ Luite [release notes]: https://downloads.haskell.org/ghc/9.6.7/docs/users_guide/9.6.7-notes.html [GHC!13841]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13841 [GHC!13891]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13891 [GHC#22010]: https://gitlab.haskell.org/ghc/ghc/-/issues/22010 [fix] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13743 [ticket] https://gitlab.haskell.org/ghc/ghc/-/issues/new

2 2

What should it mean for a record selector to be "covered"?
by Florian Ragwitz 24 Mar '25

24 Mar '25

Let's say you have data Foo = Foo { fooX, fooY :: Int } For coverage reporting, HPC creates a coverage box for each top-level definition. These boxes will be ticked appropriately at runtime when the fooX and fooY bindings are used directly. However, they won't be ticked if you pattern match on the constructor, such as f (Foo x y) = ... f Foo{ fooX = fooX } = ... f Foo{ fooX = x } = ... f Foo{ fooX } = ... f Foo{..} = ... and variations thereof. This is understandable, but can lead to some undesirable or unexpected behaviour for users of RecordWildCards or RecordPuns especially. E.g. https://gitlab.haskell.org/ghc/ghc/-/issues/17834 and https://github.com/PostgREST/postgrest/issues/2627#issuecomment-1435642297. GHC already seems to acknowledge this, at least to some extent, via its treatment of unused top-level binding warnings when using RecordWildCards, RecordPuns, or record patterns, where f Foo{ fooX } = ... or f Foo{ fooX = x } = ... will not emit a -Wunused-top-binds warning for fooX while still emitting one for fooY, and where f Foo{..} = ... will not emit any -Wunused-top-bind warnings at all. Given these observations, and assuming that the current HPC behaviour is undesirable, I’d like some guidance on what the exact desired behavior for HPC coverage should be for record selectors. In particular: * Should a record selector be considered "covered" simply by being bound in a pattern match? * Or should it only be marked as covered if the bound symbol is actually used? If the latter is preferable, would a change that initially marks them as covered upon binding (thereby aligning HPC with the treatment of unused binding warnings) be acceptable as an interim step toward the larger goal? Thanks for your time and insights!

1 0