Looks good to me. Simon On Wed, 3 Dec 2025 at 06:08, Jakob Brünker <jakob.bruenker@gmail.com> wrote:

Hey all,

our own Simon Peyton Jones proposes to simplify static pointers:

Static pointers are a feature <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/static_pointers.html> that allows you to get pointers to expressions that are valid across different processes and machines.

Allowing these expressions to reference certain types of local bindings has been producing issues that are hard to fix. The proposal suggests that instead we could just not allow that - simplifying both the specification and the implementation without placing a large burden on users (e.g. bindings can just be moved to the top level instead).

See the proposal itself for details: https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-static/proposals...

I recommend *acceptance*. The cost of trying to figure out how to support the current spec is not worth the fairly marginal gain over the proposed simplification.

It would be great if I could get your responses on this by December 10.

Thanks, Jakob

On Tue, Nov 25, 2025 at 1:54 PM Adam Gundry <adam@well-typed.com> wrote:

...

Dear Committee,

Simon proposes to simplify the specification of StaticPointers:

https://github.com/ghc-proposals/ghc-proposals/pull/732

https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-static/proposals...

I'd like to nominate Jakob as the shepherd.

Please guide us to a conclusion as outlined in

https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst#commit....

If possible, please aim to make a recommendation by 9th December 2025.

Cheers,

Adam

On 25/11/2025 12:18, Simon Peyton Jones wrote:

...

Adam

I'd like to submit this proposal to the Committee

https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-static/ proposals/0000-simplify-static.rst <https://github.com/ghc-proposals/ ghc-proposals/blob/wip/spj-static/proposals/0000-simplify-static.rst>

Thanks

Simon

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England _______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

I am also in favor. On 2025-12-03 11:20, Matthías Páll Gissurarson wrote:

I vote accept. It’s better to have a specification that works rather than one that gives rise to bugs we don’t know how to fix, and the evidence laid out in the proposal suggests that this would have minimal impact on the ecosystem. With static pointers being more broadly used for Cabal hooks, we’re better served by a clear specification and simpler implementation.

/Matti Palli

On Wed, Dec 3, 2025 at 07:07 Jakob Brünker <[1]jakob.bruenker@gmail.com> wrote:

Hey all,

our own Simon Peyton Jones proposes to simplify static pointers:

Static pointers are a [2]feature that allows you to get pointers to expressions that are valid across different processes and machines.

Allowing these expressions to reference certain types of local bindings has been producing issues that are hard to fix. The proposal suggests that instead we could just not allow that - simplifying both the specification and the implementation without placing a large burden on users (e.g. bindings can just be moved to the top level instead).

See the proposal itself for details: [3]https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj -static/proposals/0000-simplify-static.rst

I recommend acceptance. The cost of trying to figure out how to support the current spec is not worth the fairly marginal gain over the proposed simplification.

It would be great if I could get your responses on this by December 10.

Thanks, Jakob

On Tue, Nov 25, 2025 at 1:54 PM Adam Gundry <[4]adam@well-typed.com> wrote:

Dear Committee,

Simon proposes to simplify the specification of StaticPointers:

[5]https://github.com/ghc-proposals/ghc-proposals/pull/732 [6]https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-stati c/proposals/0000-simplify-static.rst

I'd like to nominate Jakob as the shepherd.

Please guide us to a conclusion as outlined in [7]https://github.com/ghc-proposals/ghc-proposals/blob/master/README .rst#committee-process-for-responding-to-a-proposal. If possible, please aim to make a recommendation by 9th December 2025.

Cheers,

Adam

On 25/11/2025 12:18, Simon Peyton Jones wrote: > Adam > > I'd like to submit this proposal to the Committee > > [8]https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-stati c/ > proposals/0000-simplify-static.rst <[9]https://github.com/ghc-proposals/ > ghc-proposals/blob/wip/spj-static/proposals/0000-simplify-static.rst > > > Thanks > > Simon

-- Adam Gundry, Haskell Consultant Well-Typed LLP, [10]https://www.well-typed.com/

Registered in England & Wales, OC335890 [11]27 Old Gloucester Street, London WC1N 3AX, England _______________________________________________ ghc-steering-committee mailing list -- [12]ghc-steering-committee@haskell.org To unsubscribe send an email to [13]ghc-steering-committee-leave@haskell.org

_______________________________________________ ghc-steering-committee mailing list -- [14]ghc-steering-committee@haskell.org To unsubscribe send an email to [15]ghc-steering-committee-leave@haskell.org

References

1. mailto:jakob.bruenker@gmail.com 2. https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/static_pointers.html 3. https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-static/proposals... 4. mailto:adam@well-typed.com 5. https://github.com/ghc-proposals/ghc-proposals/pull/732 6. https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-static/proposals... 7. https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst#commit... 8. https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-static/ 9. https://github.com/ghc-proposals/ 10. https://www.well-typed.com/ 11. https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX... 12. mailto:ghc-steering-committee@haskell.org 13. mailto:ghc-steering-committee-leave@haskell.org 14. mailto:ghc-steering-committee@haskell.org 15. mailto:ghc-steering-committee-leave@haskell.org

_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

As mentioned on the ticket, I'm in favour, _with_ a deprecation cycle. On Wed, 3 Dec 2025 at 20:56, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:

I'm in favour of this proposal. It's simple, and, I would argue, more expected than the more advanced semantics that we used to have. Static pointers aren't very much used any way, so a small regression in capabilities isn't going to be a problem.

I did ask for an extra discussion in the Alternatives section on the Github thread, for the sake of future documentation. But this doesn't need to hold my vote.

On Wed, 3 Dec 2025 at 15:08, Jakob Brünker <jakob.bruenker@gmail.com> wrote:

...

Hey all,

our own Simon Peyton Jones proposes to simplify static pointers:

Static pointers are a feature <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/static_pointers.html> that allows you to get pointers to expressions that are valid across different processes and machines.

Allowing these expressions to reference certain types of local bindings has been producing issues that are hard to fix. The proposal suggests that instead we could just not allow that - simplifying both the specification and the implementation without placing a large burden on users (e.g. bindings can just be moved to the top level instead).

See the proposal itself for details: https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-static/proposals...

I recommend *acceptance*. The cost of trying to figure out how to support the current spec is not worth the fairly marginal gain over the proposed simplification.

It would be great if I could get your responses on this by December 10.

Thanks, Jakob

On Tue, Nov 25, 2025 at 1:54 PM Adam Gundry <adam@well-typed.com> wrote:

...

Dear Committee,

Simon proposes to simplify the specification of StaticPointers:

https://github.com/ghc-proposals/ghc-proposals/pull/732

https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-static/proposals...

I'd like to nominate Jakob as the shepherd.

Please guide us to a conclusion as outlined in

https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst#commit....

If possible, please aim to make a recommendation by 9th December 2025.

Cheers,

Adam

On 25/11/2025 12:18, Simon Peyton Jones wrote:

...

Adam

I'd like to submit this proposal to the Committee

https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-static/ proposals/0000-simplify-static.rst <https://github.com/ghc-proposals/ ghc-proposals/blob/wip/spj-static/proposals/0000-simplify-static.rst>

Thanks

Simon

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England _______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

I'm in favour. I tend to agree that we don't want a deprecation cycle because this holds back actual bug fixes. The GHC maintainers could backport a deprecation warning to every next minor release to give users notice that they need to slightly refactor their code. Am Mi., 3. Dez. 2025 um 22:38 Uhr schrieb Erik de Castro Lopo < erikd@mega-nerd.com>:

Like Moritz, in favour, with a deprecation cycle if possible.

Cheers, Erik

Moritz Angermann wrote:

...

...

...

...

Cheers,

Adam

On 25/11/2025 12:18, Simon Peyton Jones wrote:

...

Adam

I'd like to submit this proposal to the Committee

https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-static/

...

...

proposals/0000-simplify-static.rst < https://github.com/ghc-proposals/

ghc-proposals/blob/wip/spj-static/proposals/0000-simplify-static.rst>

...

Thanks

Simon

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England _______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

...

...

...

Thanks, Jakob

On Tue, Nov 25, 2025 at 1:54 PM Adam Gundry <adam@well-typed.com>

wrote:

...

...

Dear Committee,

Simon proposes to simplify the specification of StaticPointers:

https://github.com/ghc-proposals/ghc-proposals/pull/732

https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-static/proposals...

...

...

I'd like to nominate Jakob as the shepherd.

Please guide us to a conclusion as outlined in

https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst#commit... .

...

If possible, please aim to make a recommendation by 9th December

...

As mentioned on the ticket, I'm in favour, _with_ a deprecation cycle.

On Wed, 3 Dec 2025 at 20:56, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:

...

I'm in favour of this proposal. It's simple, and, I would argue, more expected than the more advanced semantics that we used to have. Static pointers aren't very much used any way, so a small regression in capabilities isn't going to be a problem.

I did ask for an extra discussion in the Alternatives section on the Github thread, for the sake of future documentation. But this doesn't need to hold my vote.

On Wed, 3 Dec 2025 at 15:08, Jakob Brünker <jakob.bruenker@gmail.com> wrote:

...

Hey all,

our own Simon Peyton Jones proposes to simplify static pointers:

Static pointers are a feature < https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/static_pointers.html> that allows you to get pointers to expressions that are valid across different processes and machines.

Allowing these expressions to reference certain types of local bindings has been producing issues that are hard to fix. The proposal suggests that instead we could just not allow that - simplifying both the specification and the implementation without placing a large burden on users (e.g. bindings can just be moved to the top level instead).

See the proposal itself for details:

https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-static/proposals...

...

I recommend *acceptance*. The cost of trying to figure out how to support the current spec is not worth the fairly marginal gain over

the

...

proposed simplification.

It would be great if I could get your responses on this by December

-- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

Yes, I'm thinking the best way forward here may be a ranked choice vote about the deprecation cycle (unless we can easily agree on a deprecation plan without one). I think these are the main options we need: - Reject - Accept without Deprecation cycle - Accept, with a deprecation warning for at least one minor release (probably 9.14.2) before it's implemented - Accept, with a deprecation warning for at least one major release (probably 9.16) before it's implemented Any thoughts on this or options I'm missing? Jakob On Tue, Dec 9, 2025 at 8:35 PM Adam Gundry <adam@well-typed.com> wrote:

I'm also in favour of acceptance. It seems there is fairly clear consensus here to accept, the only question is about the deprecation cycle, as discussed here:

https://github.com/ghc-proposals/ghc-proposals/pull/732#discussion_r25839747...

My view is that we should backport a warning to 9.14.2 (and any new minor releases of earlier major series if possible), then implement in 9.16. I think that strikes a balance between making a non-broken implementation available reasonably soon, while warning users about the upcoming change.

Adam

On 08/12/2025 09:06, Sebastian Graf wrote:

...

I'm in favour. I tend to agree that we don't want a deprecation cycle because this holds back actual bug fixes. The GHC maintainers could backport a deprecation warning to every next minor release to give users notice that they need to slightly refactor their code.

Am Mi., 3. Dez. 2025 um 22:38 Uhr schrieb Erik de Castro Lopo <erikd@mega-nerd.com <mailto:erikd@mega-nerd.com>>:

Like Moritz, in favour, with a deprecation cycle if possible.

Cheers, Erik

Moritz Angermann wrote:

> As mentioned on the ticket, I'm in favour, _with_ a deprecation cycle. > > On Wed, 3 Dec 2025 at 20:56, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote: > > > I'm in favour of this proposal. It's simple, and, I would argue, more > > expected than the more advanced semantics that we used to have. Static > > pointers aren't very much used any way, so a small regression in > > capabilities isn't going to be a problem. > > > > I did ask for an extra discussion in the Alternatives section on the > > Github thread, for the sake of future documentation. But this doesn't need > > to hold my vote. > > > > On Wed, 3 Dec 2025 at 15:08, Jakob Brünker <jakob.bruenker@gmail.com <mailto:jakob.bruenker@gmail.com>> > > wrote: > > > >> Hey all, > >> > >> our own Simon Peyton Jones proposes to simplify static pointers: > >> > >> Static pointers are a feature > >> <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/ static_pointers.html <https://ghc.gitlab.haskell.org/ghc/doc/ users_guide/exts/static_pointers.html>> that > >> allows you to get pointers to expressions that are valid across different > >> processes and machines. > >> > >> Allowing these expressions to reference certain types of local bindings > >> has been producing issues that are hard to fix. The proposal suggests that > >> instead we could just not allow that - simplifying both the specification > >> and the implementation without placing a large burden on users (e.g. > >> bindings can just be moved to the top level instead). > >> > >> See the proposal itself for details: > >> https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj- static/proposals/0000-simplify-static.rst <https://github.com/ghc- proposals/ghc-proposals/blob/wip/spj-static/proposals/0000-simplify- static.rst> > >> > >> I recommend *acceptance*. The cost of trying to figure out how to > >> support the current spec is not worth the fairly marginal gain over the > >> proposed simplification. > >> > >> It would be great if I could get your responses on this by December 10. > >> > >> Thanks, > >> Jakob > >> > >> On Tue, Nov 25, 2025 at 1:54 PM Adam Gundry <adam@well- typed.com <mailto:adam@well-typed.com>> wrote: > >> > >>> Dear Committee, > >>> > >>> Simon proposes to simplify the specification of StaticPointers: > >>> > >>> https://github.com/ghc-proposals/ghc-proposals/pull/732 <https://github.com/ghc-proposals/ghc-proposals/pull/732> > >>> > >>> https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj- static/proposals/0000-simplify-static.rst <https://github.com/ghc- proposals/ghc-proposals/blob/wip/spj-static/proposals/0000-simplify- static.rst> > >>> > >>> I'd like to nominate Jakob as the shepherd. > >>> > >>> Please guide us to a conclusion as outlined in > >>> > >>> https://github.com/ghc-proposals/ghc-proposals/blob/master/ README.rst#committee-process-for-responding-to-a-proposal <https:// github.com/ghc-proposals/ghc-proposals/blob/master/ README.rst#committee-process-for-responding-to-a-proposal>. > >>> > >>> If possible, please aim to make a recommendation by 9th December 2025. > >>> > >>> Cheers, > >>> > >>> Adam > >>> > >>> > >>> > >>> > >>> On 25/11/2025 12:18, Simon Peyton Jones wrote: > >>> > Adam > >>> > > >>> > I'd like to submit this proposal to the Committee > >>> > > >>> > https://github.com/ghc-proposals/ghc-proposals/blob/wip/ spj-static/ <https://github.com/ghc-proposals/ghc-proposals/blob/ wip/spj-static/> > >>> > proposals/0000-simplify-static.rst <https://github.com/ghc- proposals/ <https://github.com/ghc-proposals/> > >>> > ghc-proposals/blob/wip/spj-static/proposals/0000-simplify- static.rst> > >>> > > >>> > Thanks > >>> > > >>> > Simon > >>> > >>> > >>> -- > >>> Adam Gundry, Haskell Consultant > >>> Well-Typed LLP, https://www.well-typed.com/ <https:// www.well-typed.com/> > >>> > >>> Registered in England & Wales, OC335890 > >>> 27 Old Gloucester Street, London WC1N 3AX, England > >>> _______________________________________________ > >>> ghc-steering-committee mailing list -- > >>> ghc-steering-committee@haskell.org <mailto:ghc-steering- committee@haskell.org> > >>> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org> > >>> > >> _______________________________________________ > >> ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > >> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org> > >> > > > > > > -- > > Arnaud Spiwack > > Director, Research at https://moduscreate.com <https:// moduscreate.com> and https://tweag.io <https://tweag.io>. > > _______________________________________________ > > ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > > To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org> > >

--

----------------------------------------------------------------------

...

Erik de Castro Lopo http://www.mega-nerd.com/ <http://www.mega-nerd.com/> _______________________________________________ ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering-committee@haskell.org> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org>

_______________________________________________ ghc-steering-committee mailing list --

ghc-steering-committee@haskell.org

...

To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

Thanks Jakob. It sounds as though everyone is happy with the end-goal of the proposal, and the only point at issue is the deprecation cycle. I think your alternatives are correct. Just to fill them out: 1. Accept without Deprecation cycle. The change would take effect in 9.16, in six months time. 2. Accept, with a deprecation warning for at least one minor release (probably 9.14.2) before it's implemented. Deprecation would start whenever 9.14.2 comes out (probably not for some months) and the change would take effect with 9.16 in about six months. 3. Accept, with a deprecation warning for at least one major release (probably 9.16) before it's implemented. Depreciation warnings would start with 9.16 in about 6 months -- and maybe in 9.14.2 as well. The change would take effect in 9.18, in a year or so. I don't think (2) buys much, because 9.14.2 will not precede 9.16 by long, if at all. (3) is a safe choice; it just has the effect of parking the actual changes for another six month; they can be merged in HEAD after the 9.16 fork. Someone hsa to remember to get around to actually doing it though. I'm very open to the committee's guidance -- but it's a judgement call and in the end a vote is probably the best way to decide it. Simon On Tue, 9 Dec 2025 at 19:41, Jakob Brünker <jakob.bruenker@gmail.com> wrote:

Yes, I'm thinking the best way forward here may be a ranked choice vote about the deprecation cycle (unless we can easily agree on a deprecation plan without one).

I think these are the main options we need: - Reject - Accept without Deprecation cycle - Accept, with a deprecation warning for at least one minor release (probably 9.14.2) before it's implemented - Accept, with a deprecation warning for at least one major release (probably 9.16) before it's implemented

Any thoughts on this or options I'm missing?

Jakob

On Tue, Dec 9, 2025 at 8:35 PM Adam Gundry <adam@well-typed.com> wrote:

...

I'm also in favour of acceptance. It seems there is fairly clear consensus here to accept, the only question is about the deprecation cycle, as discussed here:

https://github.com/ghc-proposals/ghc-proposals/pull/732#discussion_r25839747...

My view is that we should backport a warning to 9.14.2 (and any new minor releases of earlier major series if possible), then implement in 9.16. I think that strikes a balance between making a non-broken implementation available reasonably soon, while warning users about the upcoming change.

Adam

On 08/12/2025 09:06, Sebastian Graf wrote:

...

I'm in favour. I tend to agree that we don't want a deprecation cycle because this holds back actual bug fixes. The GHC maintainers could backport a deprecation warning to every next minor release to give users notice that they need to slightly refactor their code.

Am Mi., 3. Dez. 2025 um 22:38 Uhr schrieb Erik de Castro Lopo <erikd@mega-nerd.com <mailto:erikd@mega-nerd.com>>:

Like Moritz, in favour, with a deprecation cycle if possible.

Cheers, Erik

Moritz Angermann wrote:

> As mentioned on the ticket, I'm in favour, _with_ a deprecation cycle. > > On Wed, 3 Dec 2025 at 20:56, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote: > > > I'm in favour of this proposal. It's simple, and, I would argue, more > > expected than the more advanced semantics that we used to have. Static > > pointers aren't very much used any way, so a small regression in > > capabilities isn't going to be a problem. > > > > I did ask for an extra discussion in the Alternatives section on the > > Github thread, for the sake of future documentation. But this doesn't need > > to hold my vote. > > > > On Wed, 3 Dec 2025 at 15:08, Jakob Brünker <jakob.bruenker@gmail.com <mailto:jakob.bruenker@gmail.com>> > > wrote: > > > >> Hey all, > >> > >> our own Simon Peyton Jones proposes to simplify static pointers: > >> > >> Static pointers are a feature > >> <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/ static_pointers.html <https://ghc.gitlab.haskell.org/ghc/doc/ users_guide/exts/static_pointers.html>> that > >> allows you to get pointers to expressions that are valid across different > >> processes and machines. > >> > >> Allowing these expressions to reference certain types of local bindings > >> has been producing issues that are hard to fix. The proposal suggests that > >> instead we could just not allow that - simplifying both the specification > >> and the implementation without placing a large burden on users (e.g. > >> bindings can just be moved to the top level instead). > >> > >> See the proposal itself for details: > >> https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj- static/proposals/0000-simplify-static.rst <https://github.com/ghc- proposals/ghc-proposals/blob/wip/spj-static/proposals/0000-simplify- static.rst> > >> > >> I recommend *acceptance*. The cost of trying to figure out how to > >> support the current spec is not worth the fairly marginal gain over the > >> proposed simplification. > >> > >> It would be great if I could get your responses on this by December 10. > >> > >> Thanks, > >> Jakob > >> > >> On Tue, Nov 25, 2025 at 1:54 PM Adam Gundry <adam@well- typed.com <mailto:adam@well-typed.com>> wrote: > >> > >>> Dear Committee, > >>> > >>> Simon proposes to simplify the specification of StaticPointers: > >>> > >>> https://github.com/ghc-proposals/ghc-proposals/pull/732 <https://github.com/ghc-proposals/ghc-proposals/pull/732> > >>> > >>> https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj- static/proposals/0000-simplify-static.rst <https://github.com/ghc- proposals/ghc-proposals/blob/wip/spj-static/proposals/0000-simplify- static.rst> > >>> > >>> I'd like to nominate Jakob as the shepherd. > >>> > >>> Please guide us to a conclusion as outlined in > >>> > >>> https://github.com/ghc-proposals/ghc-proposals/blob/master/ README.rst#committee-process-for-responding-to-a-proposal <https:// github.com/ghc-proposals/ghc-proposals/blob/master/ README.rst#committee-process-for-responding-to-a-proposal>. > >>> > >>> If possible, please aim to make a recommendation by 9th December 2025. > >>> > >>> Cheers, > >>> > >>> Adam > >>> > >>> > >>> > >>> > >>> On 25/11/2025 12:18, Simon Peyton Jones wrote: > >>> > Adam > >>> > > >>> > I'd like to submit this proposal to the Committee > >>> > > >>> > https://github.com/ghc-proposals/ghc-proposals/blob/wip/ spj-static/ <https://github.com/ghc-proposals/ghc-proposals/blob/ wip/spj-static/> > >>> > proposals/0000-simplify-static.rst < https://github.com/ghc- proposals/ <https://github.com/ghc-proposals/> > >>> > ghc-proposals/blob/wip/spj-static/proposals/0000-simplify- static.rst> > >>> > > >>> > Thanks > >>> > > >>> > Simon > >>> > >>> > >>> -- > >>> Adam Gundry, Haskell Consultant > >>> Well-Typed LLP, https://www.well-typed.com/ <https:// www.well-typed.com/> > >>> > >>> Registered in England & Wales, OC335890 > >>> 27 Old Gloucester Street, London WC1N 3AX, England > >>> _______________________________________________ > >>> ghc-steering-committee mailing list -- > >>> ghc-steering-committee@haskell.org <mailto:ghc-steering- committee@haskell.org> > >>> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org> > >>> > >> _______________________________________________ > >> ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > >> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org> > >> > > > > > > -- > > Arnaud Spiwack > > Director, Research at https://moduscreate.com <https:// moduscreate.com> and https://tweag.io <https://tweag.io>. > > _______________________________________________ > > ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > > To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org> > >

--

----------------------------------------------------------------------

...

Erik de Castro Lopo http://www.mega-nerd.com/ <http://www.mega-nerd.com/> _______________________________________________ ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering-committee@haskell.org> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org>

_______________________________________________ ghc-steering-committee mailing list --

ghc-steering-committee@haskell.org

...

To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

Thanks, those are good points. And personally I would much rather get this done and not have to think about it in a year's time. (I know, I'm a biased witness.) Moritz (who rightly stands up for stability) has said more than once that he'd find any deprecation cycle (including (2)) acceptable. Simon On Fri, 12 Dec 2025 at 09:41, Rodrigo Mesquita <rodrigo@well-typed.com> wrote:

While it’s true that 9.14.2 and 9.16.1 may be released not too far apart, I think option (2) buys us more than you suggest:

- The timeline in which releases are made and in which releases are adopted are definitely not in sync, perhaps except for bleeding-edge users. - GHC 9.14 is meant to be an LTS release, which makes it a strong upgrade target candidate - I expect many users who adopt 9.14 will upgrade to 9.14.2 as soon as that’s out, yet wouldn’t upgrade to 9.16 upon its release

Therefore, I think a deprecation warning in 9.14.2 is in fact a pretty good middle ground between parking the MR 6 months vs. merging it without a warning.

For the record, I find option (2) is the best plan forward in this proposal.

Rodrigo

On 12 Dec 2025, at 08:41, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:

Thanks Jakob. It sounds as though everyone is happy with the end-goal of the proposal, and the only point at issue is the deprecation cycle. I think your alternatives are correct. Just to fill them out:

1. Accept without Deprecation cycle. The change would take effect in 9.16, in six months time.

2. Accept, with a deprecation warning for at least one minor release (probably 9.14.2) before it's implemented. Deprecation would start whenever 9.14.2 comes out (probably not for some months) and the change would take effect with 9.16 in about six months.

3. Accept, with a deprecation warning for at least one major release (probably 9.16) before it's implemented. Depreciation warnings would start with 9.16 in about 6 months -- and maybe in 9.14.2 as well. The change would take effect in 9.18, in a year or so.

I don't think (2) buys much, because 9.14.2 will not precede 9.16 by long, if at all.

(3) is a safe choice; it just has the effect of parking the actual changes for another six month; they can be merged in HEAD after the 9.16 fork. Someone hsa to remember to get around to actually doing it though.

I'm very open to the committee's guidance -- but it's a judgement call and in the end a vote is probably the best way to decide it.

Simon

On Tue, 9 Dec 2025 at 19:41, Jakob Brünker <jakob.bruenker@gmail.com> wrote:

...

Yes, I'm thinking the best way forward here may be a ranked choice vote about the deprecation cycle (unless we can easily agree on a deprecation plan without one).

I think these are the main options we need: - Reject - Accept without Deprecation cycle - Accept, with a deprecation warning for at least one minor release (probably 9.14.2) before it's implemented - Accept, with a deprecation warning for at least one major release (probably 9.16) before it's implemented

Any thoughts on this or options I'm missing?

Jakob

On Tue, Dec 9, 2025 at 8:35 PM Adam Gundry <adam@well-typed.com> wrote:

...

I'm also in favour of acceptance. It seems there is fairly clear consensus here to accept, the only question is about the deprecation cycle, as discussed here:

https://github.com/ghc-proposals/ghc-proposals/pull/732#discussion_r25839747...

My view is that we should backport a warning to 9.14.2 (and any new minor releases of earlier major series if possible), then implement in 9.16. I think that strikes a balance between making a non-broken implementation available reasonably soon, while warning users about the upcoming change.

Adam

On 08/12/2025 09:06, Sebastian Graf wrote:

...

I'm in favour. I tend to agree that we don't want a deprecation cycle because this holds back actual bug fixes. The GHC maintainers could backport a deprecation warning to every next minor release to give users notice that they need to slightly refactor their code.

Am Mi., 3. Dez. 2025 um 22:38 Uhr schrieb Erik de Castro Lopo <erikd@mega-nerd.com <mailto:erikd@mega-nerd.com>>:

Like Moritz, in favour, with a deprecation cycle if possible.

Cheers, Erik

Moritz Angermann wrote:

> As mentioned on the ticket, I'm in favour, _with_ a deprecation cycle. > > On Wed, 3 Dec 2025 at 20:56, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote: > > > I'm in favour of this proposal. It's simple, and, I would argue, more > > expected than the more advanced semantics that we used to have. Static > > pointers aren't very much used any way, so a small regression in > > capabilities isn't going to be a problem. > > > > I did ask for an extra discussion in the Alternatives section on the > > Github thread, for the sake of future documentation. But this doesn't need > > to hold my vote. > > > > On Wed, 3 Dec 2025 at 15:08, Jakob Brünker <jakob.bruenker@gmail.com <mailto:jakob.bruenker@gmail.com>> > > wrote: > > > >> Hey all, > >> > >> our own Simon Peyton Jones proposes to simplify static pointers: > >> > >> Static pointers are a feature > >> <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/ static_pointers.html <https://ghc.gitlab.haskell.org/ghc/doc/ users_guide/exts/static_pointers.html>> that > >> allows you to get pointers to expressions that are valid across different > >> processes and machines. > >> > >> Allowing these expressions to reference certain types of local bindings > >> has been producing issues that are hard to fix. The proposal suggests that > >> instead we could just not allow that - simplifying both the specification > >> and the implementation without placing a large burden on users (e.g. > >> bindings can just be moved to the top level instead). > >> > >> See the proposal itself for details: > >> https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj- static/proposals/0000-simplify-static.rst <https://github.com/ghc-

proposals/ghc-proposals/blob/wip/spj-static/proposals/0000-simplify-

...

static.rst> > >> > >> I recommend *acceptance*. The cost of trying to figure out

how to

...

> >> support the current spec is not worth the fairly marginal

gain

...

over the > >> proposed simplification. > >> > >> It would be great if I could get your responses on this by December 10. > >> > >> Thanks, > >> Jakob > >> > >> On Tue, Nov 25, 2025 at 1:54 PM Adam Gundry <adam@well- typed.com <mailto:adam@well-typed.com>> wrote: > >> > >>> Dear Committee, > >>> > >>> Simon proposes to simplify the specification of

StaticPointers:

...

> >>> > >>> https://github.com/ghc-proposals/ghc-proposals/pull/732 <https://github.com/ghc-proposals/ghc-proposals/pull/732> > >>> > >>>

https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-

...

static/proposals/0000-simplify-static.rst <https://github.com/ghc-

proposals/ghc-proposals/blob/wip/spj-static/proposals/0000-simplify-

...

static.rst> > >>> > >>> I'd like to nominate Jakob as the shepherd. > >>> > >>> Please guide us to a conclusion as outlined in > >>> > >>> https://github.com/ghc-proposals/ghc-proposals/blob/master/ README.rst#committee-process-for-responding-to-a-proposal <https:// github.com/ghc-proposals/ghc-proposals/blob/master/ README.rst#committee-process-for-responding-to-a-proposal>. > >>> > >>> If possible, please aim to make a recommendation by 9th December 2025. > >>> > >>> Cheers, > >>> > >>> Adam > >>> > >>> > >>> > >>> > >>> On 25/11/2025 12:18, Simon Peyton Jones wrote: > >>> > Adam > >>> > > >>> > I'd like to submit this proposal to the Committee > >>> > > >>> > https://github.com/ghc-proposals/ghc-proposals/blob/wip/ spj-static/ <https://github.com/ghc-proposals/ghc-proposals/blob/ wip/spj-static/> > >>> > proposals/0000-simplify-static.rst <

https://github.com/ghc-

...

proposals/ <https://github.com/ghc-proposals/> > >>> > ghc-proposals/blob/wip/spj-static/proposals/0000-simplify- static.rst> > >>> > > >>> > Thanks > >>> > > >>> > Simon > >>> > >>> > >>> -- > >>> Adam Gundry, Haskell Consultant > >>> Well-Typed LLP, https://www.well-typed.com/ <https:// www.well-typed.com/> > >>> > >>> Registered in England & Wales, OC335890 > >>> 27 Old Gloucester Street, London WC1N 3AX, England > >>> _______________________________________________ > >>> ghc-steering-committee mailing list -- > >>> ghc-steering-committee@haskell.org <mailto:ghc-steering- committee@haskell.org> > >>> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org

> >>> > >> _______________________________________________ > >> ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > >> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org

> >> > > > > > > -- > > Arnaud Spiwack > > Director, Research at https://moduscreate.com <https:// moduscreate.com> and https://tweag.io <https://tweag.io>. > > _______________________________________________ > > ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > > To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org

> >

--

----------------------------------------------------------------------

...

Erik de Castro Lopo http://www.mega-nerd.com/ <http://www.mega-nerd.com/> _______________________________________________ ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering-committee@haskell.org> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org

_______________________________________________ ghc-steering-committee mailing list --

ghc-steering-committee@haskell.org

...

To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

Is there a reason we can’t have a 9.14.2 release with just the deprecation warning? On Sat, Dec 13, 2025 at 1:39 PM Jakob Brünker <jakob.bruenker@gmail.com> wrote:

Sounds like we're converging on that compromise. Any objections to accepting the proposal with these provisions? - Deprecation would start whenever 9.14.2 comes out (probably not for some months) - the change would take effect with 9.16 in about six month

If not, I'll take this as consensus by December 16.

Jakob _______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

I’ve asked Zubin about this, to which he replied: A deprecation warning is not a critical bug that warrants the effort and pain of a whole new release, including costs for tooling developers, CI systems and general ecosystem fragmentation over and above the direct costs of producing a release. I still think a deprecation coming in 9.14.2 is worth it, even if released only a few months from now. To add to my points before, many folks wait for the .2 release before upgrading to a new major version. Cheers, Rodrigo

On 15 Dec 2025, at 09:10, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:

...

Is there a reason we can’t have a 9.14.2 release with just the deprecation warning?

Rodrigo can you ask Zubin about this? There are non-trivial overheads associated with a release. But a very minor release like this might have much smaller overheads?

I suppose the goal would be that the deprecation is embodied in a released GHC, much sooner than awaiting for a critical mass of bug-fixes to accumulate.

Simon

On Sat, 13 Dec 2025 at 05:14, Moritz Angermann <moritz.angermann@gmail.com <mailto:moritz.angermann@gmail.com>> wrote:

...

Is there a reason we can’t have a 9.14.2 release with just the deprecation warning?

On Sat, Dec 13, 2025 at 1:39 PM Jakob Brünker <jakob.bruenker@gmail.com <mailto:jakob.bruenker@gmail.com>> wrote:

...

Sounds like we're converging on that compromise. Any objections to accepting the proposal with these provisions? - Deprecation would start whenever 9.14.2 comes out (probably not for some months) - the change would take effect with 9.16 in about six month

If not, I'll take this as consensus by December 16.

Jakob _______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> To unsubscribe send an email to ghc-steering-committee-leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org>

---

ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org