GHC 9.12.1-alpha is now available

The GHC developers are very pleased to announce the availability
of the second alpha release of GHC 9.12.1. Binary distributions, source
distributions, and documentation are available at downloads.haskell.org.

We hope to have this release available via ghcup shortly.

GHC 9.12 will bring a number of new features and improvements, including:

  • The new language extension OrPatterns allowing you to combine multiple
    pattern clauses into one.

  • The MultilineStrings language extension to allow you to more easily write
    strings spanning multiple lines in your source code.

  • Improvements to the OverloadedRecordDot extension, allowing the built-in
    HasField class to be used for records with fields of non lifted representations.

  • The NamedDefaults language extension has been introduced allowing you to
    define defaults for typeclasses other than Num.

  • More deterministic object code output, controlled by the -fobject-determinism
    flag, which improves determinism of builds a lot (though does not fully do so)
    at the cost of some compiler performance (1-2%). See #12935 for the details

  • GHC now accepts type syntax in expressions as part of GHC Proposal #281.

  • The WASM backend now has support for TemplateHaskell.

  • … and many more

A full accounting of changes 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.

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.

As always, do give this release a try and open a ticket if you see
anything amiss.

21 Likes

The ticket doesn’t answer so I’ll ask here. What’s the reason for requiring the new flag to turn determinism on? The 1-2% slowdown should be easily paid off by better build reuse.

Since it was just introduced, it’s safe to require an active behaviour from the end-user’s part, in order to shield the rest of the users from unexpected problems. It’s pretty much a rollout flag, probably destined to disappear in the future, but right now it is required to ensure that there is no unwanted breakage.

Thanks for the clarification. I, for one, appreciate the thought given to stability, even if it means we’ll have to live with another deprecated flag for years to come.

Yeah, ultimately what’s a deprecated rollout flag, if not the mark of a successful feature that we deem ready for prime time? :slight_smile:

2 Likes