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
wrote:
Dear Committee,
Simon proposes to simplify the specification of StaticPointers:
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
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
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