
I support acceptance. Clearly communicating the stability of extensions seems like a good step towards reducing uncertainty about their use. The only reservation I have is that the proposal introduces warnings by default for all Experimental and Deprecated extensions, and with -Wall for all Legacy extensions. This seems like it could be quite noisy. It all hinges on which extensions fall into each category, though, which is not yet determined. So I'm content to wait for a follow-up proposal defining the categorisation (which will be quite a task in its own right!). We can always review the appropriate frequency of warnings when we know exactly which extensions will be warned about. It also occurs to me that extensions like NoFieldSelectors may be awkward as we might want to say that FieldSelectors is Stable but NoFieldSelectors is Experimental. But I doubt that's insurmountable, and we can resolve it in the subsequent proposal. Cheers, Adam On 24/08/2023 16:42, Simon Peyton Jones wrote:
Dear GHC steering committee
A month ago I wrote to you concerning GHC Proposal 601 about GHC extensions https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle....
We propose a categorization scheme for Haskell language extensions. This scheme is simple, in that there are few categories that are described in terms of the user-relevant aspects, and it is actionable, in that it suggests concrete changes to the warning system of GHC that allow users to express their own risk tolerance and get guidance as they upgrade their compiler
It's holiday time I know, but still, I did not get a single reply. Is that because you all love it or you all hate it? RSVP!
I propose acceptance, modulo a few clarifications which I have posted on the discussion thread.
Please reply, yea or nay.
Simon
On Tue, 25 Jul 2023 at 15:58, Simon Peyton Jones
mailto:simon.peytonjones@gmail.com> wrote: Dear GHC Steering Committee
Proposal #601 https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle... says
We propose a categorization scheme for Haskell language extensions. This scheme is simple, in that there are few categories that are described in terms of the user-relevant aspects, and it is actionable, in that it suggests concrete changes to the warning system of GHC that allow users to express their own risk tolerance and get guidance as they upgrade their compiler
I'm happy with this proposal: it seems simple, comprehensible, and actionable.
The only question in my mind is whether it is worth the bother. I'd love to hear from the practitioners on the committee.
But I propose that we accept it.
Simon
On Mon, 24 Jul 2023 at 14:39, Joachim Breitner
mailto:mail@joachim-breitner.de> wrote: Dear Committee,
David Thrane Christiansen suggested to categorize extensions into Experimental, Mature, Deprecated and Legacy, and add warning flag to GHC that allow users to be warned about (or shouted at for) using such extensions, if they choose so.
https://github.com/ghc-proposals/ghc-proposals/pull/601 https://github.com/ghc-proposals/ghc-proposals/pull/601 https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle... https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle...
Because of the meta-like aspect of this proposal, I’d like to assign this to Simon PJ.
Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process https://github.com/ghc-proposals/ghc-proposals#committee-process
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/
-- 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