- ghc-devs - Haskell.org

GHC 9.12.4-rc1 is now available
by Zubin Duggal 13 Mar '26

13 Mar '26

The GHC developers are very pleased to announce the availability of the release candidate for GHC 9.12.4. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][] and via [GHCup](https://www.haskell.org/ghcup/). GHC 9.12.4 is a bug-fix release fixing many issues of a variety of severities and scopes, including: * Fixed a critical code generation regression where sub-word division produced incorrect results (#26711, #26668), similar to the bug fixed in 9.12.2 * Numerous fixes for register allocation bugs, preventing data corruption when spilling and reloading registers (#26411, #26526, #26537, #26542, #26550) * Fixes for several compiler crashes, including issues with CSE (#25468), SetLevels (#26681), implicit parameters (#26451), and the type-class specialiser (#26682) * Fixed cast worker/wrapper incorrectly firing on INLINE functions (#26903) * Fixed LLVM backend miscompilation of bit manipulation operations (#20645, #26065, #26109) * Fixed associated type family and data family instance changes not triggering recompilation (#26183, #26705) * Fixed negative type literals causing the compiler to hang (#26861) * Improvements to determinism of compiler output (#26846, #26858) * Fixes for eventlog shutdown deadlocks (#26573) and lost wakeups in the RTS (#26324) * Fixed split sections support on Windows (#26696, #26494) and the LLVM backend (#26770) * Fixes for the bytecode compiler, PPC native code generator, and Wasm backend * The runtime linker now supports COMMON symbols (#6107) * Improved backtrace support: backtraces for `error` exceptions are now evaluated at throw time * `NamedDefaults` now correctly requires the class to be standard or have an in-scope default declaration, and handles poly-kinded classes (#25775, #25778, #25882) * ... 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][]. This release candidate will have a two-week testing period. If all goes well the final release will be available the week of 26 March 2026. 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://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.12/docs/users_guide/9.12.4-… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.12.4-rc1 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

2 1

Upcoming ghc-10.0 (formerly 9.16) fork date
by Andreas Klebinger 06 Mar '26

06 Mar '26

Hello devs, time marches and so do our plans for future releases. We plan to fork the 10.0 branch on April 1st (no not a joke). If you have work you want to see land in 10.0 please try to land it on ghc-master before that time, as we plan to do no *feature* backports beyond that point. Bugfixes of course will continue to be backport beyond the fork date. If you wonder about the supermajor version bump this was discussed in https://gitlab.haskell.org/ghc/ghc/-/issues/26198. And while ghc-10.0 will come with great features, the primary motivation is simple. Every LTS will be the last major release of a given supermajor version going forward. (9.14 being the first official LTS). This has a few benefits and overall just seemed like the least confusing option: * The last major release of any supermajor version will be it's LTS release. * The LTS release for a supermajor version will have all features present in any other major release of that supermajor release (deprecations excluded) Happy Hacking Andreas

1 0

Cabal transitive constraint puzzle
by Viktor Dukhovni 05 Mar '26

05 Mar '26

Dear Cafe and GHC-devs, I am happy to see that Yamamoto-san (cc:d) (the maintainer of the `tls` package) is extending it to include support for MLKEM key agreement. This in turn depends on the `mlkem` library by Olivier Chéron (also many thanks!). Now it turns out that for maximum portability, `mlkem` in turn has a build flag `use_crypton` that selects either `crypton`, or (current default) the older `cryptonite` library as its dependency. So the dependen graph is: tls <- mlkem <- if (use_crypton): crypton else: cryptonite But, at this, point `tls` is crypton-only, and no longer builds with the older cryptonite equivalents. Therefore `tls` adds constraints: mlkem +use_crypton to its `cabal.project` file, which solves the problem for `tls`, but sadly not for any projects that in turn depend on `tls`. To them the constraints in the `cabal.project` file of `tls` are effectively invisible. Since the default flag value in `mlkem` is for now `use_crypton: false`, each project that wants to use the (work-in-progress) `tls` appears to need to explictly know that `tls` requires a non-default build of `mlkem`, and must add the same constraints to its `cabal.project`. That transitive explicit configuration requirement is not something one can reasonably ask projects that depend on `tls to have to add. And of course, more generally, any other such indirect flag-dependent conflict must not become a burden on all consumers of library B that is only compatible with a specific variant of library C. How is this situation supposed to be handled? Is there something in cabal that can automatically convince the solver to select a setting of the `mlkem` flag that is compatible with `tls`? Must `mlkem` be forked instead to be two libraries, one dependent on `cryptonite` and another dependent on `crypton`? I've been unable to find a satisfactory workaround. Any help appreciated. -- Viktor.

5 12

Re: [Haskell-cafe] Re: Cabal transitive constraint puzzle
by Brandon Allbery 05 Mar '26

05 Mar '26

It used to be, but cryptonite has been unmaintained for a couple of years now and that's somewhat bad for a security-related package. On Thu, Mar 5, 2026 at 2:55 PM Roland Lutz <rlutz(a)hedmen.org> wrote: > On Fri, 6 Mar 2026, Viktor Dukhovni wrote: > > Bottom line, the two variants of `mlkem` don't end up offering the same > > API (distinct type signatures, that only look the same). > > Isn't this exactly what Backpack modules are for? If `mlkem` and `tls` > imported a signature for `crypton`/`cryptonite`, depending on either of > these should have `mlkem` and `tls` use the correct version of the API. > > I'm not sure what to make of "somewhat experimental", though: > https://cabal.readthedocs.io/en/stable/how-to-use-backpack.html > > > It may already have been considered, but wouldn't making `tls` compatible > with `cryptonite` solve the issue, too? > > _______________________________________________ > 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. > -- brandon s allbery kf8nh allbery.b(a)gmail.com

1 0

Call for Talks: Haskell Implementors' Workshop 2026
by Christiaan Baaij 19 Feb '26

19 Feb '26

Haskell Implementors' Workshop 2026 https://haskell.foundation/events/2026-haskell-implementors-workshop.html June 5, 2026 Organized by the Haskell Community Co-located with ZuriHac 2026 and Haskell Ecosystem Workshop 2026 Hosted by the Haskell Foundation at Eastern Switzerland University of Applied Sciences (OST) https://www.ost.ch/en/university-of-applied-sciences/campus/rapperswil-jona… Important dates --------------- Deadline: April 10, 2026 (AoE) Notification: May 8, 2026 Workshop: June 5, 2026 The 18th Haskell Implementors' Workshop is to be held alongside ZuriHac 2026 this year near Zurich. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure to share their work and to discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and short lightning talks. Scope and target audience ------------------------- The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community are encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are especially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via this form https://forms.gle/S8fpAgFaFEvqoMqH6 until April 10 (anywhere on earth). We will also have a lightning talks session. Lightning talks should be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Program Committee ----------------- * Andrew Lelechenko * Avi Press * Christiaan Baaij (chair) * Gergo Erdi * Jeffrey Young Contact ------- * Christiaan Baaij <chrisitaan.baaij at gmail.com>

1 0

Delete nofib make build system.
by Andreas Klebinger 18 Feb '26

18 Feb '26

Nofib had a shake based benchmark harness that replaced the make one for some time now. With people stopping to use the make based one it eventually bit rotted. I've been doing some refactors to fix one thing or another this week. And it's clear that the way nofibs make system currently handles package dependencies (silently expecting them to be available) is depending on your pov either completely broken or just really terrible UX. And fixing this would be non-trivial. Given the classic "make boot && make" hasn't worked for years now. So I plan to delete the make build system from it completely. If anyone has reasons against this do let me now. But unless someone is at least stepping up to fix it's handling of package dependencies I plan to follow through on it's deletion in the near future. Cheers Andreas

1 0

RFC: shutdown action of typechecker plugins
by Sam Derbyshire 16 Feb '26

16 Feb '26

Dear GHC devs, and typechecker plugin authors in particular, In GHC ticket #26935 <https://gitlab.haskell.org/ghc/ghc/-/issues/26395>, I noticed that typechecker plugins were not getting run when doing pattern match checking, which was a long standing source of frustration. I fixed this in GHC MR !14797 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14797> (only present in GHC HEAD at the moment), but, as noted in GHC ticket #26839 <https://gitlab.haskell.org/ghc/ghc/-/issues/26839>, this meant that GHC is repeatedly initialising typechecker plugins for a single module (starting and stopping the plugins for each call of initTcDsForSolver by the pattern-match checker). I am proposing to change the TcPlugin datatype to split the existing "stop" action into two separate actions, "end of typechecking" and "plugin shutdown". This would allow typechecker plugins to be kept running after typechecking (for the benefit of the pattern-match checker) while upholding the invariant that typechecker plugins are initialised once per module being typechecked (modulo small caveats about certain one-off runs of the typechecker by e.g. Backpack). The current TcPlugin data type is as follows: data TcPlugin = forall s. TcPlugin { tcPluginInit :: TcPluginM s , tcPluginSolve :: s -> TcPluginSolver , tcPluginRewrite :: s -> UniqFM TyCon TcPluginRewriter , tcPluginStop :: s -> TcPluginM () -- ^ Clean up after the plugin, when exiting the type-checker. } To allow typechecker plugins to be run by the pattern-match checker, I propose to change this to: data TcPlugin = forall s. TcPlugin { tcPluginInit :: TcPluginM s , tcPluginSolve :: s -> TcPluginSolver , tcPluginRewrite :: s -> UniqFM TyCon TcPluginRewriter , tcPluginPostTc :: s -> TcPluginM () -- ^ Action to run at the end of type-checking. , tcPluginShutdown :: s -> IO () -- ^ Clean up after the plugin, after desugaring is finished. } tcPluginPostTc would run at the end of typechecking. This gives plugins a final opportunity to modify the typechecker environment before it is finalised (as e.g. the clippy plugin does <https://github.com/ArturGajowy/ghc-clippy-plugin/blob/0f97274f238b78e1117b7…>). If the plugin relies on an active session (e.g. with Z3), the post-tc action should not end the session, because the plugin might still be invoked by the pattern match checker, later, during desugaring. Some remarks: - I changed tcPluginStop to tcPluginPostTc, because it now serves a different function (an action at the end of typechecking that should *not* shut down the plugin). Keeping the same name would be confusing, I think. - The tcPluginShutdown action runs in IO only, as running in TcPluginM would require holding on to a typechecker environment during desugaring, which can cause memory leaks. - This same change would also be carried over to defaulting plugins, but not to hole fit plugins – the latter cannot affect pattern match checking. - A better solution to all of this would be to run the pattern match checker during typechecking, but that would be a significant infrastructural change to GHC. I would like feedback from authors of typechecker plugins on this proposed change. Thanks, Sam

2 1

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

03 Feb '26

> Anyway, I'll not push my pet peeve further :) (Though I do think it's an important peeve :). Why not? If you have a good idea, push it. Hmm. So your proposal is: - When declaring a type T, specify it as a "non-updatable type" - A thunk of type T is call-by-name So in let foo = f 200 in g foo foo We'd expect (f 200) to be evaluated as many times as `g` evaluates either argument. Right? What about let bar:: Maybe T = Just (f 200) ] in ... Is bar call-by-name? Somehow wrapping in Just shouldn't change too much? Simon On Tue, 3 Feb 2026 at 08:25, Edsko de Vries <edsko(a)well-typed.com> wrote: > I think there *is* a better answer: I think (but this will require > careful consideration) that the way is is to be able to mark certain types > as "never update thunks of this type". > > Anyway, I'll not push my pet peeve further :) (Though I do think it's an > important peeve :). > > -E > On 2/2/26 11:06, Simon Peyton Jones wrote: > > PS. If you'll allow me to be cheeky for a moment: if you did want a much >> more fundamental problem to sink your teeth into, may I interest you in the >> need for call-by-name in Haskell (as opposed to call-by-need)? I've been >> writing and talking about this for almost 10 years now ( >> https://well-typed.com/blog/2016/09/sharing-conduit/, HIW 2023, in >> Seattle, IFL 2024, ..; > > > The question of when to share and when to recompute is indeed a hard one. > I wrote about it in my 1987 book > <https://simon.peytonjones.org/slpj-book-1987/>, Chapter 23. I know of > no automated solution. Lacking that we need > > - Tools for identifying the problem > - Ways of saying what we want in those cases > > The `oneShot` primitive allows you to say "use call by name for this > lambda"; we use that in GHC. You didn't mention it in your post. > > I wish I had a better answer! > > Simon > > > On Sat, 31 Jan 2026 at 06:15, Edsko de Vries <edsko(a)well-typed.com> wrote: > >> Hi Simon, >> >> The main pain point you identify is the "parallel set of instances". I >> wonder if there a design that could automate that? I think we discussed >> something along those lines years ago but I have fully paged it out. >> >> Also I wonder if there are enough compelling applications to justify it. >> Or if a good solution would unlock new applications. >> >> I'm pretty sure that that is a solvable problem, but honestly I don't >> think it's currently worth spending a lot of effort on it, given the >> unfortunately low adaption of static pointers. If you did want to improve >> the situation with static pointers, I think a more low hanging fruit would >> be to make StaticKeys more stable: across recompilation (with source code >> changes), across platforms, etc. I think that would make static pointers a >> bit more useful when deployed in a Cloud Haskell-like scenario, and perhaps >> spark some more interest. >> >> PS. If you'll allow me to be cheeky for a moment: if you did want a much >> more fundamental problem to sink your teeth into, may I interest you in the >> need for call-by-name in Haskell (as opposed to call-by-need)? I've been >> writing and talking about this for almost 10 years now ( >> https://well-typed.com/blog/2016/09/sharing-conduit/, HIW 2023, in >> Seattle, IFL 2024, ..; I also semi co-supervised a masters student on this >> topic), but I think nothing much has really changed yet. I think is an >> important problem (it affects real code that people write today) and very >> foundational (I don't know of any solutions to it, other than hacks like >> https://hackage.haskell.org/package/dupIO, our revival of Joachim's old >> package). I was going to send you my slides for my IFL talk but actually I >> think they don't make much sense without the accompanying presentation. If >> this at all sounds of interest, let me know and I can try to write down a >> summary of the problem (also happy to have a call if that's preferable). >> >> Have a good weekend :) >> >> Edsko >> >> warm good wishes >> >> Simon >> >> On Wed, 21 Jan 2026 at 17:43, Edsko de Vries <edsko(a)well-typed.com> >> wrote: >> >>> Hi Simon, >>> >>> I'll look out for the Unfoldr episode -- if you remember do send me a >>> link >>> >>> The link is >>> https://www.youtube.com/watch?v=Mc3liw0EoIY&list=PLD8gywOEY4HaG5VSrKVnHxCpt… >>> ; it will air live tonight at 7:30pm GMT, 8:30pm CET, and will be available >>> at the same link thereafter. >>> >>> -Edsko >>> >>> >>> On 1/9/26 16:21, Simon Peyton Jones wrote: >>> >>> 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> >>>>>> >>>>>

3 2

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

02 Feb '26

> > PS. If you'll allow me to be cheeky for a moment: if you did want a much > more fundamental problem to sink your teeth into, may I interest you in the > need for call-by-name in Haskell (as opposed to call-by-need)? I've been > writing and talking about this for almost 10 years now ( > https://well-typed.com/blog/2016/09/sharing-conduit/, HIW 2023, in > Seattle, IFL 2024, ..; The question of when to share and when to recompute is indeed a hard one. I wrote about it in my 1987 book <https://simon.peytonjones.org/slpj-book-1987/>, Chapter 23. I know of no automated solution. Lacking that we need - Tools for identifying the problem - Ways of saying what we want in those cases The `oneShot` primitive allows you to say "use call by name for this lambda"; we use that in GHC. You didn't mention it in your post. I wish I had a better answer! Simon On Sat, 31 Jan 2026 at 06:15, Edsko de Vries <edsko(a)well-typed.com> wrote: > Hi Simon, > > The main pain point you identify is the "parallel set of instances". I > wonder if there a design that could automate that? I think we discussed > something along those lines years ago but I have fully paged it out. > > Also I wonder if there are enough compelling applications to justify it. > Or if a good solution would unlock new applications. > > I'm pretty sure that that is a solvable problem, but honestly I don't > think it's currently worth spending a lot of effort on it, given the > unfortunately low adaption of static pointers. If you did want to improve > the situation with static pointers, I think a more low hanging fruit would > be to make StaticKeys more stable: across recompilation (with source code > changes), across platforms, etc. I think that would make static pointers a > bit more useful when deployed in a Cloud Haskell-like scenario, and perhaps > spark some more interest. > > PS. If you'll allow me to be cheeky for a moment: if you did want a much > more fundamental problem to sink your teeth into, may I interest you in the > need for call-by-name in Haskell (as opposed to call-by-need)? I've been > writing and talking about this for almost 10 years now ( > https://well-typed.com/blog/2016/09/sharing-conduit/, HIW 2023, in > Seattle, IFL 2024, ..; I also semi co-supervised a masters student on this > topic), but I think nothing much has really changed yet. I think is an > important problem (it affects real code that people write today) and very > foundational (I don't know of any solutions to it, other than hacks like > https://hackage.haskell.org/package/dupIO, our revival of Joachim's old > package). I was going to send you my slides for my IFL talk but actually I > think they don't make much sense without the accompanying presentation. If > this at all sounds of interest, let me know and I can try to write down a > summary of the problem (also happy to have a call if that's preferable). > > Have a good weekend :) > > Edsko > > warm good wishes > > Simon > > On Wed, 21 Jan 2026 at 17:43, Edsko de Vries <edsko(a)well-typed.com> wrote: > >> Hi Simon, >> >> I'll look out for the Unfoldr episode -- if you remember do send me a link >> >> The link is >> https://www.youtube.com/watch?v=Mc3liw0EoIY&list=PLD8gywOEY4HaG5VSrKVnHxCpt… >> ; it will air live tonight at 7:30pm GMT, 8:30pm CET, and will be available >> at the same link thereafter. >> >> -Edsko >> >> >> On 1/9/26 16:21, Simon Peyton Jones wrote: >> >> 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

Re: Let's fix static pointers (#26556)
by Facundo Domínguez 31 Jan '26

31 Jan '26

> in the need for call-by-name in Haskell (as opposed to call-by-need) That looks like a nice problem. Recently, Andreas Abel discussed that a bit here: https://abel-blog.github.io/when-call-by-name-outperforms-call-by-need/ I'm guessing the hard problem that still will remain in the end is diagnosing the occasional memory leak, when the developer of a project has not yet identified the need to use call-by-name in a particular case. Facundo On Sat, Jan 31, 2026 at 3:15 AM Edsko de Vries <edsko(a)well-typed.com> wrote: > Hi Simon, > > The main pain point you identify is the "parallel set of instances". I > wonder if there a design that could automate that? I think we discussed > something along those lines years ago but I have fully paged it out. > > Also I wonder if there are enough compelling applications to justify it. > Or if a good solution would unlock new applications. > > I'm pretty sure that that is a solvable problem, but honestly I don't > think it's currently worth spending a lot of effort on it, given the > unfortunately low adaption of static pointers. If you did want to improve > the situation with static pointers, I think a more low hanging fruit would > be to make StaticKeys more stable: across recompilation (with source code > changes), across platforms, etc. I think that would make static pointers a > bit more useful when deployed in a Cloud Haskell-like scenario, and perhaps > spark some more interest. > > PS. If you'll allow me to be cheeky for a moment: if you did want a much > more fundamental problem to sink your teeth into, may I interest you in the > need for call-by-name in Haskell (as opposed to call-by-need)? I've been > writing and talking about this for almost 10 years now ( > https://well-typed.com/blog/2016/09/sharing-conduit/, HIW 2023, in > Seattle, IFL 2024, ..; I also semi co-supervised a masters student on this > topic), but I think nothing much has really changed yet. I think is an > important problem (it affects real code that people write today) and very > foundational (I don't know of any solutions to it, other than hacks like > https://hackage.haskell.org/package/dupIO, our revival of Joachim's old > package). I was going to send you my slides for my IFL talk but actually I > think they don't make much sense without the accompanying presentation. If > this at all sounds of interest, let me know and I can try to write down a > summary of the problem (also happy to have a call if that's preferable). > > Have a good weekend :) > > Edsko > > warm good wishes > > Simon > > On Wed, 21 Jan 2026 at 17:43, Edsko de Vries <edsko(a)well-typed.com> wrote: > >> Hi Simon, >> >> I'll look out for the Unfoldr episode -- if you remember do send me a link >> >> The link is >> https://www.youtube.com/watch?v=Mc3liw0EoIY&list=PLD8gywOEY4HaG5VSrKVnHxCpt… >> ; it will air live tonight at 7:30pm GMT, 8:30pm CET, and will be available >> at the same link thereafter. >> >> -Edsko >> >> >> On 1/9/26 16:21, Simon Peyton Jones wrote: >> >> 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> >>>>> >>>> -- All views and opinions expressed in this email message are the personal opinions of the author and do not represent those of the organization or its customers.

1 0