- ghc-devs - Haskell.org

`INLINE_UNSAFE_COERCE`
by Wolfgang Jeltsch 15 Nov '25

15 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 09 Nov '25

09 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

Re: [Haskell-cafe] Re: GHC 9.14.1-rc2 is now available
by George Colpitts 06 Nov '25

06 Nov '25

solved it for me also. thanks! On Thu, Nov 6, 2025 at 12:44 PM Noon van der Silk <noonsilk(a)gmail.com> wrote: > Success. > > On Thu, 6 Nov 2025 at 16:41, Zubin Duggal <zubin(a)well-typed.com> wrote: > >> Try refreshing https://downloads.haskell.org/ghc/9.14.1-rc2/, >> I purged the CDN cache. >> >> On 25/11/06 12:34, George Colpitts wrote: >> >I get a 404 Not Found when I click on any of the darwin releases, e.g. >> > >> https://downloads.haskell.org/ghc/9.14.1-rc2/ghc-9.14.0.20251031-aarch64-ap… >> > >> >On Thu, Nov 6, 2025 at 12:12 PM Zubin Duggal <zubin(a)well-typed.com> >> wrote: >> > >> >> The GHC developers are very pleased to announce the availability of the >> >> second release candidate of GHC 9.14.1. Binary distributions, source >> >> distributions, and documentation are available at [ >> downloads.haskell.org >> >> ][]. >> >> >> >> The changes from the first release candidate are: >> >> >> >> * Bump the exceptions submodule to 0.10.11 >> >> * Bump the os-string submodule to 2.0.8 >> >> * Fix a driver regression causing an infinite loop with cyclic imports >> >> >> >> 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. >> >> >> >> We would like to thank the Zw3rk stake pool, Well-Typed, Mercury, >> >> Channable, >> >> Tweag I/O, Serokell, 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 have made the Haskell ecosystem what it is today. >> >> >> >> 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-rc2 >> >> [release notes]: >> >> >> https://downloads.haskell.org/ghc/9.14.1-rc2/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… >> >> _______________________________________________ >> >> Glasgow-haskell-users mailing list -- >> glasgow-haskell-users(a)haskell.org >> >> To unsubscribe send an email to >> glasgow-haskell-users-leave(a)haskell.org >> >> >> _______________________________________________ >> Haskell-Cafe mailing list -- haskell-cafe(a)haskell.org >> To (un)subscribe, modify options or view archives go to: >> Only members subscribed via the mailman list are allowed to post. > > > > -- > Noon van der Silk > > http://silky.github.io/ > > "My programming language is kindness." >

1 0

GHC 9.14.1-rc2 is now available
by Zubin Duggal 06 Nov '25

06 Nov '25

The GHC developers are very pleased to announce the availability of the second release candidate of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. The changes from the first release candidate are: * Bump the exceptions submodule to 0.10.11 * Bump the os-string submodule to 2.0.8 * Fix a driver regression causing an infinite loop with cyclic imports 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. We would like to thank the Zw3rk stake pool, Well-Typed, Mercury, Channable, Tweag I/O, Serokell, 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 have made the Haskell ecosystem what it is today. 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-rc2 [release notes]: https://downloads.haskell.org/ghc/9.14.1-rc2/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…

2 2

Static Binary with Haskell Repl
by glfmn 05 Nov '25

05 Nov '25

Hello! My name is Gwen and I am investigating an interesting problem related to tidal cycles, a haskell library for patterning music. https://tidalcycles.org/ We have the desire to distribute tidal cycles without the need for the end user to install a full haskell development environment (ghc/cabal/stack, etc). However, the interface for tidal cycles is a haskell repl. We essentially want to create an executable that will start a "pre-heated" ghci session which has the tidal libraries loaded, that we can compile on one machine with a haskell toolchain, and run on a system without one. Another use-case would be to evaluate tidal patterns authored by a musician inside of a Digital Audio Workstation. I am investigating whether this is possible. Does/could the haskell ghc api support this kind of use-case? If I was to support a similar use-case with a language like janet (which is designed to exist in a host application), the solution would be to host the compiled bytecode in the application, and populate the interpereter or virtual machine's environment with those symbols so it could find the pre-compiled bytecode hosted inside the executable. Thanks, Gwen Links with additional context: - https://github.com/haskell-hint/hint/issues/156 - https://github.com/haskell-hint/hint/issues/80

4 4

GHC 9.12.3 status update
by Zubin Duggal 28 Oct '25

28 Oct '25

Hi all, I'm currently working on the final set of backports for GHC 9.12.3-rc2. This has been delayed due to #26166 making bootstrapping GHC impossible on the new macOS release. I am currently in the process of backporting the fix for this ticket (among a few other patches) to GHC 9.12. I expect to have rc2 out in the next few days, by the end of this week. Cheers, Zubin. #26166: https://gitlab.haskell.org/ghc/ghc/-/issues/26166

1 0

GHC 9.14.1-alpha3 is now available
by Ben Gamari 09 Oct '25

09 Oct '25

The GHC developers are very pleased to announce the availability of the third alpha release of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org] 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 improvements GHCi 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] * `RequiredTypeArgments` 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 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]. 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. This is the third alpha release of 9.14.1. This comes later than expected in part due to work on a resolving a regression in the macOS 26 ([#26166]) which threatened the usability of the release. While a complete fix for this issue is not present in this alpha, we have done enough work to have confidence that it will be in finished for the release candidate which we expect should come the week of 27 October. We would like to thank the Zw3rk stake pool, Well-Typed, Mercury, Channable, Tweag I/O, Serokell, 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 have made the Haskell ecosystem what it is today. As always, do give this release a try and open a [ticket] if you see anything amiss. Cheers, - Ben [downloads.haskell.org] https://downloads.haskell.org/ghc/9.14.1-alpha3 [release notes]: https://downloads.haskell.org/ghc/9.14.1-alpha3/docs/users_guide/9.14.1-not… [ticket]: https://gitlab.haskell.org/ghc/homepage/-/issues/new [#26166]: https://gitlab.haskell.org/ghc/ghc/-/issues/26166 [#26329]: https://gitlab.haskell.org/ghc/ghc/-/issues/26329 [levels]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0682-e…

1 0