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
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…
Hi all,
Tonight (around 19:00 ET) I will be carrying out a GitLab upgrade and a
bit of work to mitigate crawler traffic. As usual, I hope this will be
less than ten minutes of downtime.
Cheers,
- Ben
