- ghc-devs - Haskell.org

Devops related changes and announcement of downtime on 2025/01/02 17:00UTC
by Magnus Viernickel 21 Dec '25

21 Dec '25

Dear GHC developers and maintainers, Now that GHC 9.14 has landed, we want to inform you about a couple of devops related changes. First of all, Debian 9 and Debian 10 have gone out of LTS support 2022 and 2024, respectively. We will stop testing these in our nightly release pipelines. In addition to our testing on Debian 11 and Debian 12, we will start testing Debian 13, as well. If you have interest in us continuing to test releases 9 and 10, please reach out to Magnus. (magnus(a)well-typed.com) Second, we will have a maintenance downtime of our Gitlab deployment on Friday, 2nd January 2026, 17:00 UTC. We are planning to have the downtime last at most two hours until 19:00 UTC but if there are any hiccups, it is possible we will have to extend this downtime, make sure you have your checkouts of GHC and the boot libraries ready before then. Last, but not least, we will make a couple of changes in the way new users are handled; new users will not be able to create /any/ repositories after they join, they will have to ask an admin for permission to create repositories. This includes forking the compiler repository. Mind that new users can still create issues on the GHC bugtracker. To make it easy for newcomers to contribute, I will make according changes in the contributing guide and I will create a new issue template for allowing to create repos. This will hopefully reduce the number of spam and advertisement repositories created. Please send a mail to Magnus (magnus(a)well-typed.com) if you have any reasonable objections to these plans. Warm regards and happy holidays (if applicable) Magnus

1 0

Naïve question: Compound instance definitions???
by Viktor Dukhovni 21 Dec '25

21 Dec '25

An existing widely-used typeclass such as `Num` cannot at present be compatibly refined to abstract a subset of its methods into more general superclasses:: class => AdditiveSemigroup a where (+) :: a -> a -> a class AdditiveSemigroup a => AdditiveMonoid a additiveIdentity :: a class AdditiveMonoid a => AdditiveGroup a negate :: a -> a (-) :: a -> a -> a class AdditiveMonoid a => CommutativeRing a where (*) :: a -> a -> a class CommutativeRing a => Num a where abs :: a -> a signum :: a -> a -- Possibly yet another class for this method. fromInteger :: Integer -> a because then all existing definitions of `Num` instances become invalid by specifying methods that no longer belong to `Num`, and failing to speicify the requisite superclass instances. As a result we can't have a satisfactory definition of addition for `Complex Integer`, because the `Num` instance has no sensible `abs` method (the square of the absolute value though integral, fails to satisfy the trianle inequality and is not compatible with abs on the corresponding complex floats). But I'm wondering whether this barrier could be overcome by allowing a single instance definitions to **implicitly** also define any requisite superclass instances by including definitions of the appropriate methods? Thus tbe below: instance Num ... where (+) :: ... additiveIdentity :: ... negate :: ... (-) :: ... (*) : ... abs :: ... signum :: ... fromInteger :: ... would be legal, and would produce implicit instances of the associated superclasses. One might then be able to define more complex `Complex` integral types: instance CommutativeRing Complex Integer where additiveIdentity = 0 :+ 0 (a :+ b) + (c :+ d) = (a + c) :+ (b + d) negate (a :+ b) = (negate a :+ negate b) (a :+ b) - (c :+ d) = (a - c) :+ (b - d) (a :+ b) * (c :+ d) = (a*c - b*d) :+ (a*d + b*c) which is not a `Num`, but is still a commutative ring. -- Viktor. 🇺🇦 Слава Україні!

1 0

A future for fusion
by Jaro Reinders 11 Dec '25

11 Dec '25

Dear Simon Peyton Jones and other interested GHC devs, In a recent thread on the issue tracker of the vector package, I was asked for my thoughts on a specific improvement to their fusion system [1]. I replied I was a bit disillusioned with GHC's approach to fusion because it is not reliable enough for the average user. Simon pointed me to a GHC plugin by Harendra Kumar which acts as a lubricant for fusion, telling GHC to inline more than usual [2]. I suggested we could integrate this into GHC by giving an inlining discount to any function which contains function that is also mentioned in a rewrite rule. However, I also noted I think this will have a large impact on code size and compilation time in larger code bases. Simon agreed, but noted that Harendra's plugin is much more selective than what I suggested. Since I think this discussion is not that relevant to the particular issue in the vector package, I'd like to continue this discussion here. To figure out what Harendra's plugin does, I skimmed the blog post and found this explanation [2]: > fusion-plugin gives programmers control through fusion annotations. > > {-# ANN type Step Fuse #-} > data Step s a = Yield a s | Skip s | Stop > > This tells the compiler: > > Any binding that scrutinizes or constructs Step must be inlined, > no matter its size. > > The plugin scans bindings during the simplifier pass: > > * If a fusible type (Step) is involved → mark it INLINE. > * Run another simplifier pass → constructors eliminated → fusion restored. Translating this to the fold/build fusion system in GHC today, we would force inlining of any function that calls `foldr` or `build` (or `augment`). Essentially, we would want to inline any binding that refers to a function that partakes in the rewrite rules for fusion. I'll admit we probably don't have to generalise this to all rewrite rules, but even with this restriction it seems like a rather aggressive optimisation strategy to me. Please correct me if I have misinterpreted anything. Cheers, Jaro [1] https://github.com/haskell/vector/issues/156#issuecomment-3623339336 [2] https://blog.composewell.com/versions/v2/posts/streamly-fusion-3.html

9 18

Representation of single-method classes
by Tom Ellis 11 Dec '25

11 Dec '25

Dear GHC friends, I would like to know whether the representation of FooD1: data Foo = MkFoo A B class FooD1 where foo :: Foo has a representation at least as efficient as FooD2: class FooD2 where fooA :: A fooB :: B in particular, that FooD1 doesn't occur an extra indirection. Now, according to https://gitlab.haskell.org/ghc/ghc/-/issues/20897 FooD1 used to be compiled as a newtype, so the answer was "yes". Then something called "Plan B" (described in that ticket) was enacted, and I believe the answer is therefore still "yes". Can someone please confirm that? For a teaser of why I want this: I find type classes very difficult to evolve in a way that satisfies my stability needs. Part of the reason for this is that type classes as typically used don't really permit any form of data abstraction: you list out all the methods explicitly in the class definition. There is no data hiding. To address this issue I am considering defining classes abstractly, like class MyClass where myClassImpl :: MyClassD for some abstract type MyClassD (i.e. whose implementation details are not exposed to users) and I want to know if there would be a performance cost. Thanks, Tom

3 6

GHC 9.12.3-rc3 is now available
by Zubin Duggal 11 Dec '25

11 Dec '25

The GHC developers are very pleased to announce the availability of the third release candidate for GHC 9.12.3. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][] and via [GHCup](https://www.haskell.org/ghcup/). GHC 9.12.3 is a bug-fix release fixing several issues of a variety of severities and scopes. A full accounting of these fixes can be found in the [release notes][]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status][]. This release candidate will have a two-week testing period. If all goes well the final release will be available the week of 22 December 2025. The changes from the first release candidate are - Fix use after free on windows due to a linker optimisation introduced in an earlier RC (#26613) - A fix for a bug in the configure script which result in the LLVM toolchain not being detected in certain situations (#26564) - Fixes for the WASM backend GHC development is sponsored by: * [Juspay](https://juspay.com/) * [QBayLogic](https://qbaylogic.com/) * [Channable](https://www.channable.com/) * [Haskell Foundation](https://haskell.foundation/) * [Serokell](https://serokell.io/) * [Well-Typed](https://well-typed.com/) * [Tweag](https://www.tweag.io/) * [Dotcom-Monitor](https://www.dotcom-monitor.com/) * [LoadView](https://www.loadview-testing.com/) * [Web Hosting Buddy](https://webhostingbuddy.com/) * [Find My Electric](https://www.findmyelectric.com/) * [Standard Chartered](https://www.sc.com) * [UpCloud](https://upcloud.com) We would like to that these sponsors 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. As always, do give this release a try and open a [ticket][] if you see anything amiss. [release notes]: https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.12/docs/users_guide/9.12.3-… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.12.3-rc3 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

GitLab read only/licensing.
by Andreas Klebinger 08 Dec '25

08 Dec '25

As many of you might have noticed GitLab forced our GitLab instance into read only mode today. We are currently working to resolve this. Without going into too much detail Ben has reach out to GitLab for a renewal of the current license over a month ago and multiple times since. Sadly GitLab hasn't been very responsive so far. I hope we can find a workaround in short order. Cheers Andreas

1 1

Strange package error -- HELP!
by Simon Peyton Jones 03 Dec '25

03 Dec '25

Friends I'm getting this from my newly-built in-tree compiler ~/code/HEAD-11/_build/ghc-stage1 -c T24984.hs -O T24984.hs:1:1: error: [ ]8;;https://errors.haskell.org/messages/GHC-45102 \GHC-45102 ]8;; \] Ambiguous module name ‘Prelude’. * it was found in multiple packages: base-4.22.0.0 base-4.22.0.0* What a bonkers message. What is going wrong? I do see this: ls -d /home/simonpj/code/HEAD-11/_build/stage1/lib/x86_64-linux-ghc-9.15.20251119/base* /home/simonpj/code/HEAD-11/_build/stage1/lib/x86_64-linux-ghc-9.15.20251119/base-4.22.0.0-c7d2 /home/simonpj/code/HEAD-11/_build/stage1/lib/x86_64-linux-ghc-9.15.20251119/base-4.22.0.0-inplace simonpj@LHR-WD-22561:~/code/HEAD-11/testsuite/tests/perf/compiler$ So there are two base packages around somehow. I don't know if that's the reason. I'd love a bit of help.. it's super annoying Maybe it's some leftover not-clean stuff -- but how would I diagnose? How can I see what package directories it is looking in, which package files it is reading? THanks Simon

2 1

Strange behaviors regarding plugin-related compiler options
by Wolfgang Jeltsch 03 Dec '25

03 Dec '25

Hi! While working with a GHC plugin, I accidentally found out the following behaviors: * The use of a plugin, at least one that is declared as pure, doesn’t make the compiled module considered unsafe even when `-fplugin-trustworthy` is missing. * Any option of the form `-fplugin-opt⟨some-garbage⟩` is accepted. Is any of these two behaviors intended? I’m using GHC 9.12.2 through Cabal. All the best, Wolfgang

1 0

GHC 9.14.1-rc3 is now available
by Zubin Duggal 02 Dec '25

02 Dec '25

The previous email had an incorrect subject line, GHC 9.14.1-rc3 is what it was intended to say. The contents following this are the same. The GHC developers are very pleased to announce the availability of the third release candidate of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. The changes from the second release candidate are: - Fix RTS segfaults in certain situations (#26495) - Fix use after free on windows due to a linker optimisation introduced in an earlier RC (#26613) GHC 9.14 will bring a number of new features and improvements, including: * Significant improvements in specialisation: * The `SPECIALISE` pragma now allows use of type application syntax * The `SPECIALISE` pragma can be used to specialise for expression arguments as well as type arguments. * Specialisation is now considerably more reliable in the presence of `newtype`s * Significant GHCi improvements including: * Correctness and performance improvements in the bytecode interpreter * Features in the GHCi debugger * Support for multiple home units in GHCi * Implementation of the [Explicit Level Imports proposal][levels] * `RequiredTypeArguments` can now be used in more contexts * SSE/AVX2 support in the x86 native code generator backend * A major update of the Windows toolchain and improved compatibility with macOS Tahoe * ... and many more A full accounting of changes can be found in the [release notes][]. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads. Note that while this release makes many improvements in the specialisation optimisation, polymorphic specialisation will remain disabled by default in the final release due to concern over regressions of the sort identified in [#26329][T26329]. Users needing more aggressive specialisation can explicitly enable this feature with the `-fpolymorphic-specialisation` flag. Depending upon our experience with 9.14.1, we may enable this feature by default in a later minor release. GHC development is sponsored by: * [Juspay](https://juspay.com/) * [QBayLogic](https://qbaylogic.com/) * [Channable](https://www.channable.com/) * [Haskell Foundation](https://haskell.foundation/) * [Serokell](https://serokell.io/) * [Well-Typed](https://well-typed.com/) * [Tweag](https://www.tweag.io/) * [Dotcom-Monitor](https://www.dotcom-monitor.com/) * [LoadView](https://www.loadview-testing.com/) * [Web Hosting Buddy](https://webhostingbuddy.com/) * [Find My Electric](https://www.findmyelectric.com/) * [Standard Chartered](https://www.sc.com) * [UpCloud](https://upcloud.com) We would like to that these sponsors 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. As always, do give this release a try and open a [ticket][] if you see anything amiss. [downloads.haskell.org] https://downloads.haskell.org/ghc/9.14.1-rc3 [release notes]: https://downloads.haskell.org/ghc/9.14.1-rc3/docs/users_guide/9.14.1-notes.… [ticket]: https://gitlab.haskell.org/ghc/homepage/-/issues/new [macos]: https://gitlab.haskell.org/ghc/ghc/-/issues/26166 [T26329]: https://gitlab.haskell.org/ghc/ghc/-/issues/26329 [levels]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0682-e…

1 0

GHC 9.12.3-rc3 is now available
by Zubin Duggal 02 Dec '25

02 Dec '25

The GHC developers are very pleased to announce the availability of the third release candidate of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. The changes from the second release candidate are: - Fix RTS segfaults in certain situations (#26495) - Fix use after free on windows due to a linker optimisation introduced in an earlier RC (#26613) GHC 9.14 will bring a number of new features and improvements, including: * Significant improvements in specialisation: * The `SPECIALISE` pragma now allows use of type application syntax * The `SPECIALISE` pragma can be used to specialise for expression arguments as well as type arguments. * Specialisation is now considerably more reliable in the presence of `newtype`s * Significant GHCi improvements including: * Correctness and performance improvements in the bytecode interpreter * Features in the GHCi debugger * Support for multiple home units in GHCi * Implementation of the [Explicit Level Imports proposal][levels] * `RequiredTypeArguments` can now be used in more contexts * SSE/AVX2 support in the x86 native code generator backend * A major update of the Windows toolchain and improved compatibility with macOS Tahoe * ... and many more A full accounting of changes can be found in the [release notes][]. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads. Note that while this release makes many improvements in the specialisation optimisation, polymorphic specialisation will remain disabled by default in the final release due to concern over regressions of the sort identified in [#26329][T26329]. Users needing more aggressive specialisation can explicitly enable this feature with the `-fpolymorphic-specialisation` flag. Depending upon our experience with 9.14.1, we may enable this feature by default in a later minor release. GHC development is sponsored by: * [Juspay](https://juspay.com/) * [QBayLogic](https://qbaylogic.com/) * [Channable](https://www.channable.com/) * [Haskell Foundation](https://haskell.foundation/) * [Serokell](https://serokell.io/) * [Well-Typed](https://well-typed.com/) * [Tweag](https://www.tweag.io/) * [Dotcom-Monitor](https://www.dotcom-monitor.com/) * [LoadView](https://www.loadview-testing.com/) * [Web Hosting Buddy](https://webhostingbuddy.com/) * [Find My Electric](https://www.findmyelectric.com/) * [Standard Chartered](https://www.sc.com) * [UpCloud](https://upcloud.com) We would like to that these sponsors 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. As always, do give this release a try and open a [ticket][] if you see anything amiss. [downloads.haskell.org] https://downloads.haskell.org/ghc/9.14.1-rc3 [release notes]: https://downloads.haskell.org/ghc/9.14.1-rc3/docs/users_guide/9.14.1-notes.… [ticket]: https://gitlab.haskell.org/ghc/homepage/-/issues/new [macos]: https://gitlab.haskell.org/ghc/ghc/-/issues/26166 [T26329]: https://gitlab.haskell.org/ghc/ghc/-/issues/26329 [levels]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0682-e…

1 0