- ghc-devs - Haskell.org

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

Reinstallable Base next steps
by Matthew Pickering 26 Nov '25

26 Nov '25

Hi all, I'm trying to establish consensus around the next stages of the reinstallable base project. It seems to me the next step is to move the `base` package out of the GHC tree into a separate repo so it can be maintained like a normal haskell package. If you have an opinion then please leave your feedback on this email thread. The issue is discussed here: https://github.com/haskell/core-libraries-committee/issues/375 and also on discourse https://discourse.haskell.org/t/what-are-the-next-steps-for-reinstallable-b… Cheers, Matt

2 1

Let's fix static pointers (#26556)
by Simon Peyton Jones 19 Nov '25

19 Nov '25

Dear Laurent, Duncan, Mathieu, Facundo, Edsko I have spent a little while digging into *static pointers* recently. See my post below. I wonder if you have any comments on my proposal? Do you know anyone else I should consult? Thanks! Simon On Fri, 7 Nov 2025 at 18:13, Simon Peyton Jones (@simonpj) < gitlab(a)gitlab.haskell.org> wrote: > Simon Peyton Jones <https://gitlab.haskell.org/simonpj> created an issue: > #26556 <https://gitlab.haskell.org/ghc/ghc/-/issues/26556> > > Static pointers are not properly implemented. For example: > > - #26545 <https://gitlab.haskell.org/ghc/ghc/-/issues/26545> > - #24464 <https://gitlab.haskell.org/ghc/ghc/-/issues/24464> > - #24773 <https://gitlab.haskell.org/ghc/ghc/-/issues/24773> > > among others. Moreover, the implementation is very messy, scattered about > in FloatOut and elsewhere. > > Let's fix it. > <#m_5415477730196602759_discussion>Discussion > > I embarked on what I thought would be a simple refactor to > > - Identify static bindings in the type checker > - Promote them to top level desugarer > > thereby avoiding all the terribly painful static-form-floating stuff that > been an ongoing source of breakage and irritation. > > Sadly it was not as simple as I had thought. Merge request !14994 > <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14994> is my work in > progress > > - > > At first it seems simple: given static e > - When typechecking e ensure that all its free variables are top-level > defined > - When desugaring, move e to top level > > Apparently simple! > - > > *Complication 1*. e might generate constraints. We don't want to solve > those from locally-bound Givens, because they'll be out of scope when we > promote to top level. > > Solution: wrap the constraints in an implication with SkolInfo of > StaticFormSkol; and in the constraint solver zap all Givens when > walking inside such an implication. That was done in > > commit 39d4a24beaa7874a69ffdc1528ca160818829169Author: Simon Peyton Jones <simon.peytonjones(a)gmail.com>Date: Tue Sep 30 23:11:19 2025 +0100 Build implication for constraints from (static e) This commit addresses #26466, by buiding an implication for the constraints arising from a (static e) form. The implication has a special ic_info field of StaticFormSkol, which tells the constraint solver to use an empty set of Givens. > > So that complication wasn't at all bad. > - > > *Complication 2*. What if we have > > f x = let y = reverse "hello" in ...(static (y++y))... > > The free vars of the static are just {y}, and y is morally-top-level. > It in turn has no free variables. > > Sadly (as it turns out) GHC tries to accept this case. When looking at > the defn of y (with no static in sight yet) the typechecker marks it > at a "static binding", meaning that it too can (and indeed must) be floated > to top level. > > So if the desugarer moves the static to the top level, it must move y > too. And that means it must mark the typechecked binding in some way, so > the desugarer can identify it. Not so hard, but there is quite a bit of new > plumbing. > - > > *Complication 3*. But what if y's RHS generates constraints, which use > Givens (or solved dictionaries, which are very similar) from its context. > E.g. > > f x = let p = x+1::Int; y = 2+3::Int in ... > > Now there may be a d :: Num Int lying around from dealing with p, and y > may use it. Oh no! Now that'll be out of scope if we move y to top > level. > > Plausible solution: use them same mechanism for static bindings as we > did for static e expressions. That is, build an implication constraint > whose SkolInfo says "zap Givens". This turned out to be considerably harder > to implement than it was for Complication 1. > - > > *Complication 4*. What if y is not generalised, perhaps because of the > Monomorphism Restriction? e.g. > > f :: Num a => a -> blahf x = let y = 3+3 in (x+y, static( ..y.. )) > > Now y is monomorphic and really does use the dictionary passed to f. > So it really cannot appear in the static. Somehow y really isn't > static after all. We must reject this program. Not only is it an > implementation mess (Complications 1,2,3 are already imposing quite a > signficant implemenation burden) but it becomes pretty hard to explain to > the programmer just which uses of static are OK and which are not. > > What a swamp. At this point I threw up my hands and wrote this summary > > <#m_5415477730196602759_proposal>Proposal > > To me the solution is clear: the rule should be > > - *in static e, all the free vars of e should be bound at top level* > > That is a nice simple rule; it is easy to explain and easy to implement. > It is also what the user manual says! > > In retrospect, by addressing Complication 2 I was trying too hard! (And > this extra feature is entirely undocumented.) I thought that I could deal > with Complication 2 using the same mechanism as the one that deals with > MonoLocalBinds. But I was wrong. > > Making this change could perhaps break some programs. They would all be > easy to fix, by moving bindings for any free variables to top level. But > note that the status quo is not stable: it has bugs e.g #24464 > <https://gitlab.haskell.org/ghc/ghc/-/issues/24464>, #26545 > <https://gitlab.haskell.org/ghc/ghc/-/issues/26545>. What we have is at > attempt to be clever that is simply wrong. > > — > View it on GitLab <https://gitlab.haskell.org/ghc/ghc/-/issues/26556>. > You're receiving this email because of your activity on gitlab.haskell.org. > Unsubscribe > <https://gitlab.haskell.org/-/sent_notifications/4b29fc65ccdc21e95267b66fdfb…> > from this thread · Manage all notifications > <https://gitlab.haskell.org/-/profile/notifications> · Help > <https://gitlab.haskell.org/help> >

1 1

GHC call today: alternative meeting link
by Sam Derbyshire 18 Nov '25

18 Nov '25

Jitsi is suffering from today's CloudFlare outage, so here's an alternate meeting link for today's GHC call: https://meet.google.com/vcq-hwba-ppo?hs=224

1 0

`INLINE_UNSAFE_COERCE`
by Wolfgang Jeltsch 16 Nov '25

16 Nov '25

Hi! I recently saw a use of the pragma `INLINE_UNSAFE_COERCE` in the `reflection` package but couldn’t find any documentation for it. What is it for? All the best, Wolfgang

2 1

Mysterious type-checking failure in connection with type equality constraint
by Wolfgang Jeltsch 13 Nov '25

13 Nov '25

Hi! Some code of mine doesn’t pass the type checker, and I have no clue to what problem GHC’s error message is meant to point. Consider the following reduced variant of my code: {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeAbstractions #-} {-# LANGUAGE PartialTypeSignatures #-} data Dict c = c => Dict class T a ~ a => C a where type T a :: * op :: C a => a -> a op = undefined fromDict :: Dict (C a) -> _ fromDict (Dict @(C a)) = op @a Feeding this to GHC 9.12.2 results in GHC telling me that it “could not deduce `w ~ (a -> a)` from the context `C a`” bound by the argument pattern of `fromDict`, where “`w` is a rigid type variable bound by the inferred type of `fromDict`”, which is “`Dict (C a) -> w`” and that this all happened “in the expression `op @a`”. After removing the constraint `T a ~ a` from the class declaration, the code is accepted. At the moment, I don’t understand at all why the presence of an equality constraint should make this program type-incorrect, and I also don’t understand the error message, in particular the role of that rigid type variable `w`. Could someone perhaps enlighten me? 🙂 All the best, Wolfgang

2 1

GHC 9.12.3-rc2 is now available
by Zubin Duggal 12 Nov '25

12 Nov '25

The GHC developers are very pleased to announce the availability of the second 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 24 November 2025. The changes from the first release candidate are * Fix a regression resulting in a panic with empty cases (#26442, #25960). * Fix for a potential segfault in the bytecode interpreter (#23210). * Fix for a regression with tabs not being allowed in string gaps (#26415). * Fix for a crash with the non-moving GC (#26204). * A rework of how internal symbols used by the code-generator are handled to adapt to changes in the Apple toolchain, enabling this release to bootstrap on macOS 26 Tahoe (#26166). 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-rc2 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

2 4

GitLab account approval
by Froxwin 10 Nov '25

10 Nov '25

Hi, I would like to contribute to GHC, so I am requesting that my GitLab account "frox" be approved, so that I can participate. Regards, Frox

3 2

GHC Steering Committee Call for Nominations
by Simon Marlow 07 Nov '25

07 Nov '25

Dear Haskellers, The GHC Steering Committee is seeking nominations for new members. *To nominate yourself *please send an email to Simon Marlow <marlowsd(a)gmail.com> <marlowsd(a)gmail.com>, briefly summarising your background and relevant experience. See below for details on what committee membership involves, and what kind of experience would be useful. DEADLINE: 6 November 2025 *What's the GHC steering committee?* The committee scrutinizes, debates and eventually decides to accept or reject proposals to change the language or major features supported by GHC. Our processes are described in the GitHub repository <https://github.com/ghc-proposals/ghc-proposals> where proposals are submitted. In particular, please have a look at the Committee bylaws <https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst>. *Who are we looking for?* We are looking for members who have the ability to: - understand GHC proposals (e.g. for new language extensions), - find holes and missing corner cases in the specifications, - foresee the interaction with other language or compiler features, - comment constructively and improve proposals through engagement with others, - judge the cost/benefit ratio of changes, and - come to a justifiable conclusion. Ideally, committee members should: - have substantial experience of writing or teaching Haskell; - have a track record of active contributions to the Haskell community; or - have expertise in language design and implementation, in either Haskell or related languages. It is our aim that this committee be diverse; by representing different viewpoints, we will make decisions that benefit larger segments of our community. Even if you are uncertain whether your background qualifies you for the role, you are warmly encouraged to apply. The committee's work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. Committee members serve for 3 years, but are free to re-nominate themselves when their 3-year term expires. Self-nominations are the norm. You can nominate someone else, but please obtain their explicit consent to do so. (We don't want to choose someone who turns out to be unable to serve.) *What happens after nominations?* In accordance with our Committee bylaws <https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst>, the committee deliberates nominations *in private* before communicating the decision. The committee doesn't have a fixed size, although we like to have a minimum of 9 members. There are currently two members rotating off, but as the committee currently has 10 members, we will be looking to appoint at least one but possibly (hopefully!) more. On behalf of the committee, Simon Marlow

1 1