Thanks Edsko. Great episode! 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. warm good wishes Simon On Wed, 21 Jan 2026 at 17:43, Edsko de Vries <[email protected]> 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=PLD8gywOEY4HaG5VSrKVnHxCptlJv2GAn7&index=54 > ; 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 <[email protected]> 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/proposals/0000-simplify-static.rst>. >> 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 < >> [email protected]> 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) < >>> [email protected]> 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 <[email protected]>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/4b29fc65ccdc21e95267b66fdfb679af/unsubscribe> >>>> from this thread · Manage all notifications >>>> <https://gitlab.haskell.org/-/profile/notifications> · Help >>>> <https://gitlab.haskell.org/help> >>>> >>>
_______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
