# Proposal to simplify (static e) slightly: call for comments

**URL:** <https://discourse.haskell.org/t/proposal-to-simplify-static-e-slightly-call-for-comments/13290>\
**Category:** Announcements\
**Created:** [November 19, 2025, 11:58am UTC](https://discourse.haskell.org/t/proposal-to-simplify-static-e-slightly-call-for-comments/13290 "2025-11-19T11:58:29Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![simonpj](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/simonpj/32/890_2.png) [@simonpj](https://discourse.haskell.org/u/simonpj)\
**Post date:** [November 19, 2025, 11:58am UTC](https://discourse.haskell.org/t/proposal-to-simplify-static-e-slightly-call-for-comments/13290/1 "2025-11-19T11:58:29Z")

</div>

Do you use the `StaticPointers` extension at all ([manual entry](https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/static_pointers.html))? Or Cloud Haskell?

I’m proposing to simplify the specification of `(static e)` expressions very slightly, which might affect you.

**Here is the [GHC proposal](https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-static/proposals/0000-simplify-static.rst)**.

I would love to hear if you have any thoughts about this. Thanks!

---

<div class="post-metadata">

**Author:** ![LaurentRDC](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/laurentrdc/32/4950_2.png) [@LaurentRDC](https://discourse.haskell.org/u/LaurentRDC)\
**Post date:** [November 19, 2025, 5:59pm UTC](https://discourse.haskell.org/t/proposal-to-simplify-static-e-slightly-call-for-comments/13290/2 "2025-11-19T17:59:07Z")

</div>

Looking around for users of static pointers, [I found that Cabal’s new setup hooks use static pointers under the hood](https://github.com/haskell/cabal-proposals/blob/master/proposals/setup-hooks.md#proposed-design-of-rules)!

---

<div class="post-metadata">

**Author:** ![simonpj](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/simonpj/32/890_2.png) [@simonpj](https://discourse.haskell.org/u/simonpj)\
**Post date:** [November 19, 2025, 11:00pm UTC](https://discourse.haskell.org/t/proposal-to-simplify-static-e-slightly-call-for-comments/13290/3 "2025-11-19T23:00:23Z")

</div>

Interesting! Is there any way you could

- Look at the code and assess whether this proposal would impact it?
- Find out who wrote that code and invite them to comment on the proposal?

Thanks!

Simon

---

<div class="post-metadata">

**Author:** ![chrisdone](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/chrisdone/32/1408_2.png) [@chrisdone](https://discourse.haskell.org/u/chrisdone)\
**Post date:** [November 20, 2025, 9:03am UTC](https://discourse.haskell.org/t/proposal-to-simplify-static-e-slightly-call-for-comments/13290/4 "2025-11-20T09:03:49Z")

</div>

I’m not a user of CloudHaskell, so can’t “weigh in” on the proposal.

But I found it very interesting. Going back to the original manual entry, a superficial reading by a user may lead one to think it’s sufficient to have a `Typeable` instance, and to not consider that actually this seems more to be about a lexical/syntactic restriction not reflected in the types.

It’s hard not to have Template Haskell come to mind, as splices and Lift have related restrictions. And with Lift you can derive a serialisation to a file with Haskell syntax and then load that syntax in again in GHCi (almost Lisp-like). I’ve been exploring this in my Hell scripting language for the purpose of easily dumping and loading a data structure where the storage format is simply Hell/Haskell code, and thought Lift (without Q in the type) would be one angle.

Obviously, static itself is of interest to me, too, because I could in theory change ([this](https://github.com/chrisdone/hell/blob/main/src/Hell.hs#L520)) `Lit :: a → Exp g a` to contain a `StaticPtr a` after type checking is done, and write that to disk, or send over network, as “bytecode.” Similar use case to CloudHaskell, but much more modest.

Feels like there’s a broader formalisation that would handle both the dynamic Lift case and the static pointer case, in terms of recognizing a complete closed term, avoiding the warts, but remains to be seen.

---

<div class="post-metadata">

**Author:** ![simon](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/simon/32/3292_2.png) [@simon](https://discourse.haskell.org/u/simon)\
**Post date:** [November 21, 2025, 7:52am UTC](https://discourse.haskell.org/t/proposal-to-simplify-static-e-slightly-call-for-comments/13290/5 "2025-11-21T07:52:04Z")

</div>

I am looking at static pointers as a mechanism to compare functions.

From looking at the proposal, it seems to me that expressive power remains the same and only some convenience is lost. If we disregard sharing of `y`, one can always move the let variable inside the static scope manually:

```haskell
let y = "Hello" in static (reverse y)

```

becomes

```haskell
static (let y = "Hello" in reverse y)

```

Is that right?

If no expressive power is lost and this proposal frees up GHC developer time to work on other things, then I am all for it.

---

<div class="post-metadata">

**Author:** ![simonpj](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/simonpj/32/890_2.png) [@simonpj](https://discourse.haskell.org/u/simonpj)\
**Post date:** [November 21, 2025, 8:53am UTC](https://discourse.haskell.org/t/proposal-to-simplify-static-e-slightly-call-for-comments/13290/6 "2025-11-21T08:53:36Z")

</div>

> [@simon](#):
>
> If we disregard sharing of `y`, one can always move the let variable inside the static scope manually:

Correct. Indeed that exact example is (now) given in Section 6. All good.

---

<div class="post-metadata">

**Author:** ![simonpj](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/simonpj/32/890_2.png) [@simonpj](https://discourse.haskell.org/u/simonpj)\
**Post date:** [November 21, 2025, 8:55am UTC](https://discourse.haskell.org/t/proposal-to-simplify-static-e-slightly-call-for-comments/13290/7 "2025-11-21T08:55:05Z")

</div>

> [@chrisdone](#):
>
> Feels like there’s a broader formalisation that would handle both the dynamic Lift case and the static pointer case, in terms of recognizing a complete closed term, avoiding the warts, but remains to be seen.

Indeed Matthew Pickering has been thinking about exactly this, as Section 5 now mentions. But this proposal is about a very narrow point, leaving open the possiblity of a more thorough-going update if someone makes proposal for that.

---

<div class="post-metadata">

**Author:** ![mpickering](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mpickering/32/4585_2.png) [@mpickering](https://discourse.haskell.org/u/mpickering)\
**Post date:** [November 24, 2025, 10:47am UTC](https://discourse.haskell.org/t/proposal-to-simplify-static-e-slightly-call-for-comments/13290/8 "2025-11-24T10:47:32Z")

</div>

@chrisdone

I think that a TH quotation is analogous to the `static` keyword, since they both are about lexical/syntactic properties of expressions.

`Lift` is useful for converting dynamic values into a TH AST. The analogous class for `Static` would be something like `Binary`.

It is an interesting idea you propose whether you could implement `static` by sending bytecode over the network rather than creating a shared static pointer table. If you did this you would still need an interpreter in your binary to evaluate the bytecode, but you would be able to handle executing “unknown” programs.

---

<div class="post-metadata">

**Author:** ![simonpj](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/simonpj/32/890_2.png) [@simonpj](https://discourse.haskell.org/u/simonpj)\
**Post date:** [November 24, 2025, 11:03am UTC](https://discourse.haskell.org/t/proposal-to-simplify-static-e-slightly-call-for-comments/13290/9 "2025-11-24T11:03:10Z")

</div>

I think this proposal is about ready to submit to the committee.

Does anyone have anything else they’d like to add.

(NB: I have changed it quite a bit since originally posting it, so you might want to take another look.)

One open question is about deprecation cycles. I think that:

- No one has said that their code even uses the current ability to deal with nested defintions
- The currently impelementation has genuine bugs that cannot readily be fixed withotu this change

So I’m inclined to propose that we just implement this change without a deprecation cycle; that is, without preserving the bugs for a year while deprecating any nested definitions.

Any views?

---

<div class="post-metadata">

**Author:** ![LaurentRDC](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/laurentrdc/32/4950_2.png) [@LaurentRDC](https://discourse.haskell.org/u/LaurentRDC)\
**Post date:** [November 24, 2025, 2:02pm UTC](https://discourse.haskell.org/t/proposal-to-simplify-static-e-slightly-call-for-comments/13290/10 "2025-11-24T14:02:52Z")

</div>

I’m also inclined to eschew a deprecation cycle for this. As mentioned in the proposal, I’m happy to help any affected user of Cloud Haskell. I’ll just need to make sure that everything is buildable during the appropriate GHC release process, before the final release.

The proposal refers to this [bug report](https://gitlab.haskell.org/ghc/ghc/-/issues/24464); will the change you propose make `distributed-closure` unbuildable?

---

<div class="post-metadata">

**Author:** ![simonpj](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/simonpj/32/890_2.png) [@simonpj](https://discourse.haskell.org/u/simonpj)\
**Post date:** [November 24, 2025, 5:35pm UTC](https://discourse.haskell.org/t/proposal-to-simplify-static-e-slightly-call-for-comments/13290/11 "2025-11-24T17:35:37Z")

</div>

> [@LaurentRDC](#):
>
> The proposal refers to this [bug report](https://gitlab.haskell.org/ghc/ghc/-/issues/24464); will the change you propose make `distributed-closure` unbuildable?

On the contrary, it’ll fix it the bug!

The code in the bug report is

```haskell
class C a where
  f :: a -> StaticPtr ()
  f _ = static ()

```

That obeys all the rules – there are no free varialbes of the `static`. It’s terrible that it’s rejected today.