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