- ghc-devs - Haskell.org

Re: Let's fix static pointers (#26556)
by Simon Peyton Jones 10 Jan '26

10 Jan '26

Great thanks Edsko -- v helpful. By the way, I am not entirely sure why the proposal mentions the IsStatic class > explicitly, but I just wanted to mention that it is really quite useful; I > declare two instances in my Unfolder episode :) The proposal mentions IsStatic only because I wanted to give the expansion that GHC performs. I agree that it's useful, but it's really orthogonal to the proposal. I'll look out for the Unfoldr episode -- if you remember do send me a link Thanks again Simon On Fri, 9 Jan 2026 at 12:25, Edsko de Vries <edsko(a)well-typed.com> wrote: > Hi Simon, > > Apologies for my slow reply. It's been nearly 15 years (!) since I wrote > distributed-process and distributed-static (fun fact: it was my first > task when I joined Well-Typed) and I felt I needed to set aside some time > to properly page everything back in, as I haven't really used static > pointers ever since (somewhat sadly..). I realize that the proposal how now > been written and accepted, so this email comes too late in a way, but I > finally had some time now to look at this properly. In hindsight, the > proposal is simple enough, but I didn't realize that at the time. > > Anyway. The proposal is fine with me :) I seems to me that it's no more > than a minor inconvenience to the programmer. I have now prepared a Haskell > Unfolder episode (which will likely be the next episode we air, episode > #53) on static pointers, where I discuss the primitive building blocks > provided by ghc, and show how we can implement some compositional > infrastructure around that (including some thoughts on type classes, which > I believe you and I discussed a very long time ago). I'll also mention the > proposal and the upcoming changes in 9.14.2 (warning) and 9.16 (change > implemented). I tried building it with your branch (wip/T26718) and that > all worked fine. I also added one module in which your branch issues the > warning expect, and that seemed good also. > > By the way, I am not entirely sure why the proposal mentions the IsStatic > class explicitly, but I just wanted to mention that it is really quite > useful; I declare two instances in my Unfolder episode :) > > -Edsko > On 11/19/25 13:02, Simon Peyton Jones wrote: > > Thanks Laurent and Mathieu > > *Edsko, Duncan, Facundo*: do you have any views? > > I have now written a GHC proposal > <https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-static/proposal…>. > Could you add your thoughts to it? I think it's a no-brainer myself, but > we should go through the proper process. > > Do any of you know people I should consult? Eg authors of libraries that > use StaticPtrs? > > Thanks > > Simon > > > > On Fri, 7 Nov 2025 at 21:18, Simon Peyton Jones < > simon.peytonjones(a)gmail.com> wrote: > >> 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. >>> 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 >>> >>> 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 0

Critical code generation bug with GHC 9.12.3
by Zubin Duggal 08 Jan '26

08 Jan '26

Hello all, Unfortunately we discovered a major code generation regression in GHC 9.12.3 that results in incorrect runtime results for certain operations involving sub-word divisions. We recommend avoiding upgrading to this minor release at this time. See https://gitlab.haskell.org/ghc/ghc/-/issues/26711 for more details. This is the same bug that affected GHC 9.12.1. A patch re-introducing this bug was accidently backported onto the 9.12.3 branch and went unnoticed throughout the testing period. We are taking steps to ensure similar situations are less likely to occur again, including looking at ways to improve our testing procedure for minor GHC release, potentially using the Stackage infrastructure to run the testsuites of a broad range of packages to detect such issues. We are also starting to prepare GHC 9.12.4 with a fix, which we hope to release soon. However, a significant amount of time has passed since the initial set of backports to GHC 9.12.3 were completed, which means that a number of merge requests addressing issues of various severities has been marked for backporting to the GHC 9.12 branch. We are in the process of triaging this list and preparing a robust and reliable GHC 9.12.4 release. Thanks, Zubin.

1 0

Static forms deprecation warning
by Simon Peyton Jones 04 Jan '26

04 Jan '26

Zubin The accepted GHC proposal 732: Simplify static forms <https://github.com/ghc-proposals/ghc-proposals/pull/732> needs a deprecation warning added to GHC 9.14, to warn about static forms that mention nested free variables. Ticket #26718 <https://gitlab.haskell.org/ghc/ghc/-/issues/26718> tracks the warning. I have implemented that warning in branch wip/T26178 in the main GHC repo. It's based on the ghc-9.14 branch. I'm not sure how to run CI on it. Can I hand it off to you now? It should be part of the 9.14.2 release as agreed by the GHC steering committee. RSVP Thanks Simon

1 0

GitLab account no longer working and unable to recover?
by Iustin Pop 29 Dec '25

29 Dec '25

Hello, Sorry, from https://gitlab.haskell.org/ghc/ghc/-/wikis/report-a-bug it's not clear if there's a specific list for gitlab issues or not. I wanted to report a bug surfaced by HLS, but it looks like my account or password no longer works, and I can't recover the password. The account page is still up, with my correct email address: https://gitlab.haskell.org/iustin, but the recovery option doesn't work. I checked and the recovery emails don't land in spam. Any hints? thanks! iustin

1 1

GHC 9.14.1 is now available
by Zubin Duggal 28 Dec '25

28 Dec '25

The GHC developers are very pleased to announce the release of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. GHC 9.14 brings 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 * Greatly improved [SSE/AVX2 support][sse] in the x86 native code generator backend * Initial native code generator support for LoongArch * The WebAssembly backend now supports [evaluation via the interpreter][wasm-ghci], allowing GHCi and TemplateHaskell evaluation, including `foreign import javascript` usage from within the browser * A new primop [`annotateStack#`][annotate-stack] for pushing arbitrary data onto the call stack for later extraction when decoding stack traces * [`-Wincomplete-record-selectors`][incomplete-selectors] is now part of `-Wall`. Libraries compiled with `-Werror` may need adjustment. * A major update of the Windows toolchain * Improved compatibility with [macOS Tahoe][macos] * ... and many more A full accounting of changes can be found in the [release notes][]. See the [migration guide][] for guidance on migrating programs to this release. Note that while this release makes many improvements in the specialisation optimisation, polymorphic specialisation remains disabled by default in the 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 thank 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 comprises 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 [release notes]: https://downloads.haskell.org/ghc/9.14.1/docs/users_guide/9.14.1-notes.html [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… [wasm-ghci]: https://www.tweag.io/blog/2025-04-17-wasm-ghci-browser/ [incomplete-selectors]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0516-i… [annotate-stack]: https://gitlab.haskell.org/ghc/ghc/-/issues/26218 [migration guide]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.14 [sse]: https://gitlab.haskell.org/ghc/ghc/-/issues/25030

3 2

GHC 9.12.3 is now available
by Zubin Duggal 28 Dec '25

28 Dec '25

The GHC developers are very pleased to announce the release of GHC 9.12.3. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. GHC 9.12.3 is a bug-fix release fixing many issues of a variety of severities and scopes, including: * Fix a number of crashes and miscompilations in the compiler frontend (#25004, #25960, #26256) * Improvements to efficiency of the runtime linker (#26009) * Fixes for several bugs in bytecode generation and the bytecode interpreter (#23210, #25975, #25750) * Fixes for bugs in the handling of WHITEHOLEs in the RTS (#26204, #26205) * Fix incorrect code generation for SSE vector operations (#25859) * Fix a use-after-free in the Windows runtime linker (#26613) * Support for synchronous JSFFI exports for the wasm backend * And many more! 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][]. 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) * [Mercury](https://mercury.com) We would like to thank 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://downloads.haskell.org/~ghc/9.12.3/docs/users_guide/9.12.3-notes.html [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.12.3 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

2 1

Missing instances in `dump-decls` output
by Wolfgang Jeltsch 26 Dec '25

26 Dec '25

Hi! It seems that `dump-decls` of GHC 9.12.2 misses instances. For example, I cannot find the `Functor` instance of `Data.Functor.Product.Product` in `tests/interface-stability/base-exports.stdout`. In the `HEAD` version it is present, though. Is this a known problem? Which `base-exports.stdout` files are reliable? The one of GHC 9.14.1? The one of `HEAD`? All the best, Wolfgang

1 0

Old feature branches
by Wolfgang Jeltsch 22 Dec '25

22 Dec '25

Hi! Is it actually intended that references to feature branches that have already been merged into `master` stay in the GHC repository? There is a lot of branch references in this repository, which sometimes makes it a bit hard to find a particular one that you’re looking for. Should I delete my own obsolete feature branch references? All the best, Wolfgang

2 1

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

22 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