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: Accept without Deprecation cycle. The change would take effect in 9.16, in six months time.
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.
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 <mailto: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 <mailto: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> <mailto: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> <mailto: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> <mailto: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 <http://typed.com/> <mailto: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/ <http://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/ <http://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> <mailto:ghc-steering- <mailto:ghc-steering-> committee@haskell.org <mailto:committee@haskell.org>> > >>> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:leave@haskell.org> <mailto:ghc-steering-committee-leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org>> > >>> > >> _______________________________________________ > >> ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:committee@haskell.org> <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> > >> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:leave@haskell.org> <mailto:ghc-steering-committee-leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org>> > >> > > > > > > -- > > Arnaud Spiwack > > Director, Research at https://moduscreate.com <https://moduscreate.com/> <https:// moduscreate.com <http://moduscreate.com/>> and https://tweag.io <https://tweag.io/> <https://tweag.io <https://tweag.io/>>. > > _______________________________________________ > > ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:committee@haskell.org> <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> > > To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:leave@haskell.org> <mailto: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:committee@haskell.org> <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:leave@haskell.org> <mailto: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>
-- 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 <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>
ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org